[nycphp-talk] email system for website

Rolan Yang rolan at
Mon Jan 4 15:41:10 EST 2010

Paul A Houle wrote:
> Matt Juszczak wrote:
>>>   The term "REST" is an early predictor for project failure a year 
>>> or two down the road.  More than once I've been the guy who cleans 
>>> up the mess after somebody ignorantly blunders into using "REST" for 
>>> something that it's not appropriate for.
>> Well, we didn't go that route.  We had three choices: Put database 
>> logic inside the webserver code base, put it in the database, or put 
>> it somewhere in the middle.  We decided on putting it in the 
>> database, which ties us to using MySQL, but allows us to write a lot 
>> more front ends a lot easier.
>    The architecture where "multiple processes communicate with a 
> shared database" gets less credit than it deserves.  In your case I 
> think there's no reason you can't write your batch scripts in PHP:  
> pretty commonly I write command line scripts that run as cron jobs...  
> In that situation,  you can use
>    to fork the same way you would in Perl.  I tend to do long-running 
> tasks as cron jobs that are scheduled to run for a certain time (maybe 
> 4 minutes) and that get respawned every so often (say 5 minutes.)  You 
> do need some logic to prevent them from getting stacked up when things 
> go wrong,  but this works pretty well.

My initial approach used cron jobs, but then one day things did stack up 
under high volume and I ended up rewriting the mail engine to run under 
CLI using the Pear System_Daemon library. Works like a charm now. Sleep 
for one minute, then check for any new unsent emails in the queue and 
process. As a bonus, I was able to throw in some functions that manage 
events and triggers based on specific times or elapsed time periods.


More information about the talk mailing list