[nycphp-talk] email system for website
Rolan Yang
rolan at omnistep.com
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
>
> http://php.net/manual/en/function.pcntl-fork.php
>
> 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.
~Rolan
More information about the talk
mailing list