(as discussed in IRC chat:) Long long ago BugZilla sends _one_ email per bug update and adding all people into TO:/CC: fields. Starting with the recent BugZilla update _single_ emails are send for _each_ user (15 people in CC means that at least 16 emails are send (previously: _One_ email !!)). This new behaviour is going to be a performance problem for large sites like universities or large providers, heavy BugZilla use may put even the largest Email servers (E420R) _down_. Additionally it isn't "easy" anymore to use a simple "Reply To All" to reach all people via PM - now you've to fetch all users manually from the bug's HTML page...
also as discussed in irc, the difference here is that oldemailtech created one email with n recipients for each bug change. newemailtech creates n bug mails, with one per recipent. All this extra mail causes extra server load. This is apparently a big deal on Roland's servers. I haven't yet noticed any change on lounge yet but anything that reduces stress there would be greatly appreciated. Since newemailtech is the default for 2.12 we thought that this should probably be fixed before the 2.12 release.
> All this extra mail causes extra server load. > This is apparently a big deal on Roland's servers. Not my servers. I don't have the money to buy them... :-) > I haven't yet noticed any change on lounge yet but > anything that reduces stress there would be greatly appreciated. AFAIK "lounge" only relays emails, right ? Realying emails isn't a problem (but you have to handle extra bandwidth, too) - receiving&sort-in of emails is the problem. Processing an email is expensive as it blocks one "worker" process for sort-in (wait for file locks, parse and process email etc.). One worker process can feed multiple mailboxes without huge pain. But sending multiple emails instead of one can quickly eat-up all worker processes. The machine's CPUs aren't busy - but all worker processes are busy doing things (adding more worker processes isn't wise as this will fail in the case that one worker process has to feed multiple mailboxes...) and other emails have to be queued until a worker process get's free. (You have the same problem with mailinglists. Think about a mailinglist with 8000 subscribers... Ouch...)
Dave thinks that doing this wouldn't be much, if any of a savings. cc'ing him. i'll let him comment.
You only save something if you have people in CC: bugzilla.mozilla.org may not benefit a lot from these optimisations - but some BugZilla sites put more than five people into CC - and this starts to _count_. Think about a Medical lab which uses a hacked version of BugZilla - each incoming "plate" (6x24 samples per plate) is a "bug". You've to care for the customer, the engineers, a Dr. who plays the "QA" (checks that the results are OK), the Prof. who likes to be informed about all details in the lab and so on. - usally seven or eight people in the TO:/CC: fields. Each "bug" - until finished get's ~20 comments until finished, ~90 plates/day Simple math: 90*20*1=1800 90*20*8=14400 OK... please tell me again that this won't save anything... =:-)
OK, here's bugzilla.mozilla.org's impact for this... Typically, bugs get a large number of CCs on them (15 or 20). The majority of addresses listed are at a variety of hosts. With the exception of netscape.com, very few people are at the same host. If Bugzilla generates one email per user, it has to deliver one email out of the system for each user. If Bugzilla generates one email per bug, it STILL has to deliver one email out of the system for each user, because they're all on different systems, so the MTA has to clone the message and send out a copy for each recipient anyway. The only place that b.m.o would see savings from this is in a case where a large number of the CCs are @netscape.com, since those would all be sent in one message with multiple recipients to netscape.com's mail server, and they'd be split up there. OK, now let's say you're in a closed shop where everyone accessing Bugzilla is picking up their email from the same system. If one email is sent for the bug, the receiving mail system STILL has to clone the message and drop a copy of it in each mailbox for each of the users. In this case, the only difference I can see is the use of network bandwidth. The receiving system would have to receive over the network a copy for each user, or it could receive one message then split it up. However, 14400 emails per day amounts to about 4 emails per second, and that's enough to keep a mailserver decently busy. If all your recipient mailboxes are on the same machine, I don't see how you're significantly impacting the load by changing which way the mail is sent.
Didn't Terry make this change (sending out one email per recipient) to allow to make the content of the email configurable by the user in the future? Is the impact on your mail server really that big? Do we really need this for 2.12? (Or at all?)
Yes, this is there to allow mail to be configured for the user in future.
So this bug should be marked WONTFIX? Otherwise we would need an admin pref for this. Don't know if this is worth the effort.
> So this bug should be marked WONTFIX? The worst thing which may happen is that large providers start to cancel/reject BugZilla emails, treating them as SPAM... - do you like _that_ ??
What has that got to do with this bug?
Example: Seven months ago we got a lot of trouble of one of the large german providers because one or mailing lists produced an incredible amount of emails (one per subscribed recipient, few hundret postings/day)... The real problem was that a self-written mailinglist filter did not create one email with a large list of recipients - instead it created single emails. The result was that the provider banned our _whole domain_ because this little mailinglist bot created too much mail traffic...
I don't see the similarity to this case. There are no bugs I know of with lots of people from the same external domain which gets hundreds of postings a day. Normally a bug has many CC:s but on different servers (b.m.o) or many people from the same local system (private installations). In no case would the scenario painted by Roland apply. I say we close this bug report and in the rare case of any external user having problems either reopen this (if it would help) or recommend that they disable oldemailtech. Not that I think that would ever be necessary.
Yes, I agree. If you want to reduce bug spam, work on improving email controls (bug #69253, bug #71912, etc), or aggregating bulk notifications (bug #26943).
Filed bug 71935 about me not getting bugmail from b.m.o any more.
Based on the discussion above, is this really a 2.12 blocker? Cc Dawn, you added that target milestone.
based on above discussion, removing 2.12 target milestone.
We should discuss this during 2.16. Given that bug #26194 and bug #86201 are targetted for 2.16 also I doubt we will be doing this as is. However, we might want to consider merging the notifications if the options for two users are all the same (eg unchanged from default) ... however AFAIK this either means using BCC to all the users (and hence might run afoul of filters), or using To. The latter would let users know who had the same options as them, possibly a privacy issue.
Mass moving to new product Bugzilla...
With recent changes to Bugmail, we are moving farther away from the being able to send one e-mail for all users on one bug change. Oldemailtech used to send one bugmail and cc all the relevant people, but that mail scheme is long gone from bugzilla. Even adding this ability as an administrative pref would add a level of complexity that isn't justified by the returns.