Performance of e-mail sending

[tgilbert328]

Before I begin, I suggest that you purchase O’Reilly’s sendmail 3rd editon by Bryan Costales and read chapter 6 from cover to cover. It is there were I learned this tip, and there are likely many other important tips in there that I did not implement or understand.

Firstly, I found an important change that I made to improve performance was to define two queues, one for sending with very fast (low) time-out values and a second queue with the conservative time-outs (5 minutes is default for OpenSUSE 10.2).

The reason is that what I found were there were many slow mail servers which while doing reverse lookups and other spam related testing, took some time to response to my HELO. These slow servers were causing sendmail to spawn new sendmail instances which in turn caused a much higher memory usage. By defining two queues called sendmail-fast and sendmail-normal I added 50% more emails per hour! (mileage would depend on the quality of the email servers in your list)

Here is how I did it.

Firstly, there is a file in /etc/mail called linux.mc. I made a copy of that file and called it linux-fastqueue.mc. To the bottom of the linux-fastqueue.mc file, I added these lines:

Code: Select all

dnl TMG: Added to set this queue to only wait for 4 seconds for a response.
define(`TO', `4s')dnl
define(`confTO_ICONNECT', `TO')dnl
define(`confTO_CONNECT', `TO')dnl
define(`confTO_COMMAND', `TO')dnl
define(`confTO_DATAINIT', `TO')dnl
define(`confTO_HELO', `TO')dnl
define(`confTO_HOSTSTATUS', `TO')dnl
define(`confTO_INITIAL', `TO')dnl
define(`confTO_MAIL', `TO')dnl
define(`confTO_QUIT', `TO')dnl
define(`confTO_RCPT', `TO')dnl
define(`confTO_RESOLVER_RETRANS', `TO')dnl
define(`confTO_RESOLVER_RETRY', `TO')dnl
define(`confTO_RSET', `TO')dnl
define(`confTO_DATABLOCK', `TO')dnl
define(`confTO_DATAFINAL', `TO')dnl

Then I saved the file.

I compiled the file with this command:

Code: Select all

m4 linux-fastqueue.mc > /etc/sendmail-fastqueue.cf

which creates another configuration file in the /etc directory.

Next, I modified this file:

Code: Select all

/home/openemm/bin/mailer.sh

And changed these lines:

Code: Select all

mproceed "mail queue"
$sm -q1m -NNEVER -OQueueDirectory=$BASE/var/spool/QUEUE -OPidFile=/var/run/sendmail-openemm-queue.pid

To this:

Code: Select all

mproceed "mail queue"
$sm -q5m -L sendmail-normal -C /etc/sendmail.cf  -NNEVER -OQueueDirectory=$BASE/var/spool/QUEUE -OPidFile=/var/run/sendmail-openemm-queue.pid
$sm -q1m -L sendmail-fast   -C /etc/sendmail_fastqueue.cf -NNEVER -OQueueDirectory=$BASE/var/spool/QUEUE -OPidFile=/var/run/sendmail-openemm-queue-fast.pid

This defines two mail queues, one called sendmail-normal which has the standard definitions as defined in sendmail.cf and a second called sendmail-fast which uses the new settings. This also causes fast to create new instances every minute while creating the other instances every 5 minutes.

The effect of this change is that the fast configuration will time-out any SMTP server which doesn’t quickly answer. Later, the –normal version will pick it up and process with the 5 minute timeouts.

I am sure there are improvements to be made, and I am experimenting with QueueSortOrder=random for the fast queue to speed up initial queue scans. I wanted to share this information now so that others could benefit from my experimentation.

[Dabbler]

37,500 multi-part e-mails, 39KB in size, in 5 hours = 7,500/hour

CentOS 4.5
Sendmail 8.13.1-3.2.el4
MySQL: 4.1.20 (Redhat's distribution)
JDK: 1.6.0_01
Python 2.3.4

2.8 GHz dual Xeons w/4GB RAM
Shared with a very large, very busy vBulletin forum site that tends to get cpu-bound.
E-mails sent in the wee hours, so little to no impact from competing app.

We're upgrading to a bigger machine with faster layers, so I'll update in about a month.

[tgilbert328]

WARNING:

My post above about reducing the time-outs did in fact result in a problem with at least one particular user receiving many copies of the same email. It turned out that the mail server was timing out AFTER the final stages of sending resulting in multiple attempts each reported as a time out, but each also appears to have resulted in successful send.

I think that the 4 secs is too aggressive and I will consult the manual to figure out at which steps I need to increase the time-out to prevent this. In the meantime, I have backed out the changes.

Tim

[patm]

Hello,

We have populated our recepient database with >300K users and the system has slowed right down. Specifically when you try and open the recipient lists. We have tried to implement this fix from this thread

Open the file webapps/openemm/htdocs/recipient/list.jsp in an editor.

Find the line:
sqlStatement=sqlStatement.replaceAll("cust[.]bind", "bind");

Add this line after it:
sqlStatement+=" LIMIT 1000";

It should now look like this:
sqlStatement=sqlStatement.replaceAll("cust[.]bind", "bind");
sqlStatement+=" LIMIT 1000";
System.err.println("Statement: "+sqlStatement);


but we are using a different version so it doesn't apply. Is this a known issue with 5.3.0 and it there a fix? I have put in our list.jsp below for review.

sqlStatement=sqlPrefix+sqlStatement;
if(targetRep.generateSQL().length() > 0 && targetRep.checkBracketBalance()) {
sqlStatement+=" AND "+targetRep.generateSQL();
}
sqlStatement=sqlStatement.replaceAll("cust[.]bind", "bind");
sqlStatement+="Statement: "sqlStatement);
%>

<agn:ShowTable id="agntbl1" sqlStatement="<%= sqlStatement %>" startOffset="<%= request.getParameter("startWith") %>" maxRows="50">
<tr>
<td><bean:message key="<%= new String("gender."+(String)pageContext.getAttribute("_agntbl1_gender")+".short") %>" />&nbsp;</td>
<td><%= pageContext.getAttribute("_agntbl1_firstname") %>&nbsp;</td>
<td><%= pageContext.getAttribute("_agntbl1_lastname") %>&nbsp;</td>
<td><agn:ShowByPermission token="recipient.view">

Sorry to be a pain.

Thanks

Pat.

[csl-computer]

I tested openemm with a recipient list with a size of 280k.
Our old newsletter system sends our 280k emails in about 12 to 13 hours.
I thought this is a poor performance, but the test with openemm was about 30000 email in 11 hours.
Very strange ... our old newsletter system works with postfix ... seems to be the better choice!

[christian.lang]

I tested openemm with a recipient list with a size of 280k.
Our old newsletter system sends our 280k emails in about 12 to 13 hours.
I thought this is a poor performance, but the test with openemm was about 30000 email in 11 hours.
Very strange ... our old newsletter system works with postfix ... seems to be the better choice!

That depends on your point of view ...
OpenEMM inserts the mails into a normal sendmail queue. So for example if your server is being greylisted or you have sent to many mails to a single server to fast OpenEMM will try to resend the emails till a quite late timeout.

For example in our case there was a small percentage of mail-adresses which caused 4.x.x errors which caused resends. Many of them were outdated domains.

When we started using OpenEMM the process of sending mails was considerably slower than now because many/most of these mails got deactivated by OpenEMMs bounce handling.

[csl-computer]

I read OpenEMM doesn't need sendmail anymore in version 5.5 ... has anyone experience if the performance is now acceptable or on the level of the old 5.4 version?