Matt Juszczak wrote:
So how about this:
For things like password recovery, private message notifications,
welcome emails, etc. that are initiated by the user and are only sent
to one user, I'll do those in the code base (the negative being I have
to code that twice, in both front ends).
For things like thread subscriptions, user subscriptions, alerts,
etc., which could potentially go to multiple users, I'll do those in
the background with a cron.
Does this make sense?
Sure, but I'd also send "high priority" and "low priority" emails
through separate systems (sendmail/postfix/whatever instances.)
It's highly desirable that people get email verification and
password recovery messages as quickly as possible. If these get
delayed, you run into all sorts of wetware problems, such as people
losing their motivation to complete the registration process.
If you've got, say, 250k outbound bulk messages in your queue,
however, the delivery of messages could be delayed by minutes, hours,
or even days.
With two separate mail servers, you can avoid all of these
headaches. Personally, I like running the "high priority" mail server
on the same machine as the web server, and running bulk mail on a
dedicated machine. You can go be a fashionable virtualization-head if
you wish, but I'll warn you that heavily loaded mail servers use
fsync() in a way that interacts very badly with database servers and web
servers...
_______________________________________________
New York PHP Users Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/Show-Participation
