Lack of interest Make default for enableMailQueue = false

This suggestion has been closed automatically because it did not receive enough votes over an extended period of time. If you wish to see this, please search for an open suggestion and, if you don't find any, post a new one.
digitalpoint

digitalpoint

Well-known member
While XenForo's mail queue system is nice for sites that use SMTP at the application level to send mail, I would guess that most sites don't do that, and rely instead on the normal MTA of the server (sendmail, Postfix, etc.), which is a mail queuing system in itself. So ultimately enableMailQueue defaulting to "true" means that most sites are using a mail queue at the application level to queue into the server's mail queue.

For some reason I missed that XenForo was doing this, and finally figured out why there seemed to be a lag on mail XF sends out.

Ultimately this was the fix:
PHP: 
$config['enableMailQueue'] = false;

So now it just queues into the normal server mail queue directly (queuing into XF's mail queue vs. the server's mail queue has no bearing on the user experience/speed).
 
Upvote 2
This suggestion has been closed. Votes are no longer accepted.
Hmm I wonder if this will solve an issue we recently ran into with Postfix. We send out all mail via SMTP but use Postfix to do it at the server level instead of XenForo.
 
This phrase within acp>mail would be helpful: "If you enable Email over SMTP enable the mail queue in library/config.php: ... $config['enableMailQueue'] = false; ..." ... or simply direct to xenforos manual about enabling the mail queue in the configuration.
 
There isn't really a reason for it to be delayed though, even on a small board. On a small board, the mail queue should be triggered by the user submitting the post (as it should come back telling them to hit deferred.php); on a big board, even if that didn't happen, the next page view should trigger it. (If you're triggering config.php via cron, it should be running each minute at the least so you'd be seeing a max of 60 seconds delay, unless you have a huge number of emails to send. If you're triggering via cron, you should be increasing the timeout from the default 8 seconds.)
 
Yeah, we trigger deferred via a cron every 60 seconds. With Googlebot running JS these days, we were getting 50-75 calls to deferred.php per second 24/7. A 60 second delay is still a delay... Not saying it made things unworkable, just was curious why the delay was happening was all. Not a huge deal since there is a config setting to disable the queue... Just a little pointless to queue at the application level so we can queue into the MTA.

For sites doing SMTP at the application-level, it's a great feature... I just think those are probably the minority is all.
 
I actually use the application mail queue + an addon to ensure mail isn't lost when dispatching to the outbound gateway on a separate box from the php worker. This avoids having to fight with postfix configuration for shuffling email around internally before it is forwarded to the outbound gateway.

A delay in mail isn't so much of an issue, compared to handling when a popular thread generates a few hundred emails from a new reply without needing to compromise on short page timeouts.
 
Did some more testing this morning... Using XF's mail queue does seem to be about 60% faster for queuing email vs. Zend's Sendmail transport (PHP's mail() function).

What would really be nice would be to use the deferred system for bulk email sending (things like sending notifications/emails when someone posts in a forum that 1,000 people watch), then the time to queue emails really becomes a non-issue. Right now you get noticeable lag for the user when they trigger an action that sends a lot of emails (again, the biggest culprit is people watching popular forums). ~37 seconds to send 1,000 emails directly with mail(), but the 23 seconds required to queue those same 1,000 into the XF mail queue is still not good when the user is trying to post a new thread and they sit there for 23 extra seconds.

Deferred please for that stuff. :)
 
Back
Top Bottom