SMTP slower than PHP mail method?

[Stefaans]

Everywhere I read, the advice is to use SMTP for the fastes possible sending of lists. My experience so far has been the opposite...

We are hosting a newsletter with 600,000 subscribers for a client. I am seeing a sending rate of about 5,5500 emails per hour using the SMTP method. When switching to the PHP mail() method, the rate goes up to about 7,500 per hour. Why is SMTP not doing better?

Previously, we used DADA Mail for the newsletter. I had a similar experience there with SMTP being slower. So this is not a ListMailPro problem. If anything, our system needs tweaking.

We are using a dedicated server for the newsletter. It runs cPanel with Exim mail server. I prefer sending out messages as ListMailPro generates them, rather than queing them for later delivery. Here are all the SMTP and queue related settings in /etc/exim.conf:

Code: [Select]

#
#smtp settings
smtp_accept_max = 0
smtp_accept_queue_per_connection = 0
smtp_connect_backlog = 50
#
#queue settings
split_spool_directory = yes
queue_run_in_order = no
remote_max_parallel = 5
queue_run_max = 5
queue_only_load = 5


Any suggestions for tweaking SMTP for better performance? Thanks

[DW]

SMTP is recommended for reliability.  I can't necessarily recommend it for speed over PHP mail() as I have never run comparative tests.  From the speeds you report I assume your individual messages are fairly large, 10k to ~25k - is that right?  I recommend checking out the server (SMTP) mail queue to see how many messages there are waiting to be delivered.  If a considerable number of messages cannot be delivered it may affect performance adversely.  I would have to search around a bit to find out the correct commands to do this as I have limited experience with Exim...  Actually, I believe you can view the total number in queue from the WHM/Server administration panel.  If this number is high (ie. over 10,000) when not sending email there may be a problem with delivery to certain domains due to blocks or blacklisting.  Having a huge number of messages in queue (>75000) will greatly slowly dow hard drive access to the queue folders, which would probably slow down your mailings greatly.

Please let me know if I can be of further assistance!

Regards

[listmailpro]

Stefaans - This is all depending on how your provider / host is set up, but here's what I know about the two sending methods. PHP is often faster because it's simply generating a bunch of emails and doing one of two things with them:
A) Sending them all directly to the recipients email server, which is hard to program and I don't believe how ListMailPro handles it, or
2) Handing them all over to the SMTP server on your end, but all at once or in groups of preset amounts

The problem is, depending on how your provider treats large amounts of email, it's queue rules, etc. it is a considerably safer idea to use SMTP. With SMTP, you're establishing a connection and handing off the emails INDIVIDUALLY. Yes, you can set ListMail to hand it off slower, in groups, then pause, another group, pause, but it's still technically saying to the SMTP server (mind you, very quickly), here's an email, here's an email, etc. The point is, if SMTP can't deliver one instantly, it moves it to the back of the line and continues, but still only has to technically handle one at a time. With PHP, it's true that assuming the SMTP server can keep up, it'll get done much faster, but if it lags, you may actually lose a bunch of emails or they get pushed off for 8, 12, 24 hours if the queue is filled up with other people's mail. Again, it all depends on the settings your provider uses, but yes, PHP will appear faster, but is not what I'd recommend.

[Stefaans]

Thanks, these are all helpful replies.

DW: The likely cause of the "slow" transmissions is that the server resides in the USA and the subscribers on the other side of the Atlantic in South Africa. We are doing this to avoid a huge bandwidth bill. That's another story I will not bore you with now Probably around 20% of emails go to the queue. I think the reason for that is two-fold: delays in delivery (because of the geographic issue) and high server load (I am pushing as hard I can). I can see that with a big mail queue goes a high IOwait and a decrease in speed. Some of the emails in the queue ultimately bounce. So, I expect this issue to improve somewhat as bounced users are eventually removed.

listmailpro: Thanks for the technical explanation. I will stick to SMTP for reliability, even if it means a slower rate.

I am currently looking at other ways to speed up things, like using a second server. Thanks again for your perspectives.