On Sat, Apr 12, 2008 at 1:06 AM, Dave Rolsky <[EMAIL PROTECTED]> wrote: > On Fri, 11 Apr 2008, Jonathan Rockway wrote: > > > > In an ideal world, you should be able to dump the messages into your > > mail system's queue as quickly as you can dump them into a database > > table (adding to the mail queue is a disk write, adding to a database is > > a disk write, unless you've turned off data integrity). > > > > I could see how calculating the text of 10000 mail messages during a > > request would be slow, but why would you want to do that? Usually > > you'll just want to say "Your account was created, [% name %]!" and > > queue that. The template rendering and the mail system's queue should > > be more than fast enough to handle that during a request. > > > > As for bulk emails, you probably have a process that calculates those > > outside of your Catalyst app anyway (running from cron), so calculate > > them, dump them into the mail queue, and let your mailer daemon figure > > out what to do. Much better than putting a queue in front of a queue, > > IMHO. This is UNIX after all. > > > > The big problem I've run into when sending lots of emails from a web app > (just hundreds, in this case), is that it can be slow enough the browser > times out. > > Presumably you could have a similar problem with a work queue as well. > > Ultimately, I suspect a solution that forks _immediately_ and then does its > thing (whatever that thing may be) is going to be necessary past a certain > scale. > > Then the trick becomes monitoring that forked process. > > Another solution might be to come up with a way to queue up the job with a > single write and do the full email generation via cron. Either way, you have > to add complexity to your app if you want to provide feedback on the job > status to the user. > > I'll be working on this soon for an app I'm creating, and I suspect I'll go > the route of doing a single insert and processing via a cron job. The upside > of this is that for a multi-user app, I won't end up forking a whole bunch > of email sending processes and I can exercise some control over the rate > that email is generated. >
My first approach was to do the sending in a cron job - but then came the requirement that the emails should be sent as soon as possible. Now I have a forking model, but I don't know if I implemented it correctly (the mod_perl guide recommends against forking http://modperlbook.org/html/10-2-Forking-and-Executing-Subprocessesfrom-mod_perl.html). I am also contemplating a compromise of sending the first few emails immediately and the rest from a cron job. > > -dave > > /*========================== > VegGuide.Org > Your guide to all that's veg > ==========================*/ > > > > _______________________________________________ > List: [email protected] > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/[email protected]/ > Dev site: http://dev.catalyst.perl.org/ > -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
