Closed Bug 71630 Opened 23 years ago Closed 23 years ago

BugZilla should only send _one_ email for _one_ bug update...

Categories

(Bugzilla :: Email Notifications, defect, P3)

2.13
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: roland.mainz, Assigned: jacob)

References

Details

(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.
Target Milestone: --- → Bugzilla 2.12
> 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.
Target Milestone: Bugzilla 2.12 → ---
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.
Severity: critical → normal
Priority: -- → P3
Target Milestone: --- → Bugzilla 2.16
Mass moving to new product Bugzilla...
Assignee: tara → jake
Component: Bugzilla → Email
Product: Webtools → Bugzilla
Version: other → 2.13
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.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Target Milestone: Bugzilla 2.16 → ---
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.