Greg Stark wrote:
> A better plan for such systems is to have a queue in your database for
> parameters for e-mails to send. Insert a record in the database and let your
> web server continue processing.
>
> Have a separate process possibly on a separate machine or possibly on multiple
> machines do selects from that queue and deliver mail. I think the fastest way
> is over a single SMTP connection to the mail relay rather than forking a
> process to inject the mail.
>
> This keeps the very variable -- even on your own systems -- mail latency
> completely out of the critical path for web server requests. Which is really
> the key measure that dictates the requests/s you can serve.
>
Exactly, Greg. This is homologous to proxy serving http requests. Ideally, the
data/text
should be relayed to a separate, dedicated mail server. This has come up
repeatedly
for me on performance tuning projects. If there are a number of mail processes
negotiating
with remote hosts even running on the same machine as you are web serving from,
you may,
under significant load, degrade performance.
