A frequent problem we see at client sites is when they click submit on a page, whether it is a creation of a node or a comment, and then the site does not come back for several minutes.
The problem sometimes is due to connections to third party servers for Web 2.0 services, but can also be due to modules that send emails. For example, Organic Groups can be configured to send emails to all group members when a new post is submitted, or when someone comments on an article, ...etc.
So far, each module had to implement its own solution to this issue. For example, organic groups solves this problem by relying on the excellent job queue module. The subscriptions module has a settings for sending notifications via cron rather than at node/comment submission time.
Up until now, there was no generic way to make all emails sent from Drupal be sent when cron runs.
We wrote the queue mail module to address this requirement. It intercepts emails send from Drupal, and then uses the job queue module for the actual sending.
This way, any module that sends emails is prevented from slowing down page loads for end users.
Comments
Visitor (not verified)
thank you!
Mon, 2008/10/27 - 10:13this is EXACTLY what i have been waiting for - without it, any sort of notifications module brings a site to crawl...the node has to check for all subscriptions,and process for all...you have saved the day!
this should be in core imho, as message handling and cron have already found most of their way in there...
Khalid
Thanks but no ...
Mon, 2008/10/27 - 11:02Thanks, but I disagree that it should be in core.
Core is doing exactly what it should: provide extensible and flexible APIs for other modules to use.
By having those APIs, people can extend their sites any way they want, which may not be the same way that the next person wants.
So, our module uses the API from core for email, and the API for job_queue. Other modules may or may not want to do it in other ways.
Having it in core will just make core bigger, and force one way to do things.
We avoid that by having lean APIs only.
--
2bits -- Drupal and Backdrop CMS consulting
Visitor (not verified)
Big thanks to all the people
Mon, 2008/10/27 - 14:10Big thanks to all the people from 2bits for yet another important release! I'm off to begin testing...
Alan Dixon (not verified)
Alternatively ...
Thu, 2017/02/16 - 10:41If the slow down is due to your php configured to use an external smtp connection for the mail() function, then another way to fix the problem is to not do that, and instead use the local mail configured as a relay out to that external smtp server.
In general, using external smtp as a default mail solution causes problems exactly like this in multiple places, might as well let your local mail server do the work of handling outgoing mail complexities (connection overhead, etc).
Of course, requires root access.
Yeah, you're an old unix guy, I thought you'd appreciate it.
Khalid
Default is slow
Thu, 2017/02/16 - 10:55The article was written after the issue was found with the default PHP configuration. That is, PHP invokes a command (default is /usr/sbin/sendmail -t -i on Debian/Ubuntu), and that is slow. Hence the queuemail module.