What's the URL of the page containing the problem? N/A What steps will reproduce the problem? 1. Have a slow mail server. 2. Create/modify a review such that an email is sent. 3. Notice that reviewboard is slow or AJAX calls seem to be unresponsive. What is the expected output? What do you see instead? Submitting/modifying a review should not be slow because it is waiting for emails to be sent. What operating system are you using? What browser? N/A Please provide any additional information below. If email sending was asynchronous, submission/modification could be committed and then email sent (at whatever speed necessary) without affecting the responsiveness of the UI.
- Type-Defect + Type-Enhancement + Component-EMail
It might be best to move our e-mail support into a hook script that's run out of process. This would be a 2.0 thing.
I'm adding a vote to fix this: the fact that Publish takes a long time (5-7 seconds) means people press the button twice and get multiple posts. It's also a major annoyance and it's hindering the adoption of this fantastic tool in the organization. I hope it gets fixed sooner than 2.0...
The problem is, we're relying upon Django's e-mail functionality, and we have no control over the method in which that is sent. Fixing this in Review Board involves a lot of reimplementation. It definitely shouldn't be that slow, though, unless the connection with the server is really slow or maybe if there are hundreds of users it's trying to send to (at which point this depends on the server). The problem is, we either have to call out to some external process to talk to the server (in order to prevent blocking) or talk to the server ourselves. It's not unreasonable to talk to it ourselves, so long as the conversation with the server is quick. Which it should be. Are you using mailing lists for the groups? If not, it's sending to each member individually. What e-mail software are you using?
I'm using Exchange. There are about 5 people in the default reviewer list; but AFAICS the email is sent just once (I see everyone in the To: list). There aren't a lot of concurrent users at all in our RB (just starting to use it), so I can't imagine it's due to load. I'm running it on Ubuntu in VMWare with about 500MB of RAM. I would try using a distribution list for the default reviews group, but I can't imagine that would change much since the email seems to be sent to all of them together.
That's awfully slow for that few users. It might be worth putting some logging in place to see where the slow part is (both analyzing the traffic to/from Exchange and just logging around the mail sending code using log_timed). We use Review Board with thousands of developers on a very busy Exchange server and haven't hit slowdowns like this, so I'm really curious as to what's going on.
Well I'm pretty sure it's not Exchange that's taking up the time. It's generally very fast here and Publish is consistently very slow. I'm not entirely sure where/how to put the logging code. I haven't really familiarized myself with RB code yet, just installed it. I'll try to figure it out.
One thing that helped my email performance for ReviewBoard greatly was to use Postfix on the local box as a mail relay. ReviewBoard has the local postfix daemon as its smtp server and then postfix relays the email along later. This covers both the main smtp being down and also if it is slow to respond. The only downside has been that it takes about a minute or two longer for the mail to actually arrive in people's mailboxes, but its not really a time critical send.
I'm going to merge this with bug 1068, since I think using an MTA is by far the best way to "make it asynchronous"
- Confirmed + Duplicate
+ 1068 - Use a Mail Transfer Agent (MTA) to send mail instead of a mail server listening at a TCP/IP port