Mail Performance

Anon

I am benchmarking a messaging site which is based on php scripts. The bottleneck on performance is the call to sendmail via the php in-built mail() function. Is there a way to run this function in background mode or has anyone else found a work-around for this problem?

Anon

Well the only thing I came up with is to add the outgoing messages to a database and have a sentinal program/script (a constantly refreshing script?) watch the database for any changes and then have that program/script perform the actual email functions.

Anon

Can't you call sendmail directly with a "&" at the end to force it into the background?

Anon

Thanks for the suggestion. I'll try it - if I can work out what all the correct parameters are to set and pass to sendmail when running it directly - dont suppose you have an example?

The other idea I am pursuing is trying out the performance using SMTP to talk to the mail daemon on the machine jsut in case the performance delay is anything to do with mail() causing a program to load and unload into memory.

If all these fail then I'll resort to writing to a database/file and have a cron job do the sending asynchronously.

Anon

man sendmail should give you an idea on how to use it.

Basically you just pipe the email data to it directly.
Just make sure the format is correct.

Something like:
To: user@somewhere
From: me@overhere
body data
EOF

is usually enough.
But read the manual to get the full info.

Oh, and make sure, I mean really sure, that what you are passing to sendmail
does can not have any naughty commands in it, or you could be giving a hacker some serious opportunities.

Anon

Out of interest here are the results of comparing using sendmail in background vs SMTP vs sendmail in foreground on a dedicated Linux 500MHz server with PHP 3.0.16

The script I am running is maxing out at about 2 emails (3k long) per second using the PHP mail function. About 20% of the time is being used by the call to sendmail.

Calling sendmail in background from PHP gave about a 5-8% improvement in overall speed.

Calling via SMTP was unreliable and seemed to hit a bug with reading from the server and hang. My guess was that the receive buffer regularly missed part of the responses
(i.e it wasn't buffering) anything before I calle dthe read statement and so between the write and read there was enough time on a fast server to drop some of the response?