Optimizing Performance

---

[Envelope Phase] [Message Phase] [Keeping messages small] [How many threads?] [Statistics window]

This section describes how to get the best possible mail sending performance out of CustomMailer.  

The primary thing to know is that the sending performance of CustomMailer is almost entirely determined by the speed of your internet connection and the size of your email message.  CustomMailer processing time itself (expanding macros, wrapping lines, etc.) is almost inconsequential.  When CustomMailer is sending mail, most of the time it is sitting idle waiting from responses from your SMTP server.

Sending a email message involves two phases of exchanging information between CustomMailer and your SMTP server:
    Envelope Phase: say hello to the server, authenticate if necessary, identify mail sender, and identify mail recipients
    Message Phase: transmit the message itself.

Let's look at these phases and how to optimize each of them.


Envelope Phase
During the Envelope Phase, CustomMailer initiates a session with the SMTP server, possibly performs SMTP authentication, identifies the mail sender (from address), and identifies the mail recipient(s) (to, cc, and bcc addresses).  The most unpredictable part of this operation occurs during identification of recipients.  This is because your SMTP server has to perform a DNS (Directory Name Service) look-up for each of the addresses to make sure they are valid Internet domains. This operation usually amounts to a fraction of a second but can sometimes take several seconds, and when you send email internationally, this can sometimes take 10's of seconds because accessing a DNS server in a different country may be required.  Most of this time, CustomMailer, your internet connection, and your SMTP server are all idle, with your SMTP server waiting for DNS responses from the Internet.  The Envelope Phase can go even slower if your SMTP server is overloaded, or the internet connection to the outside for your company is overloaded, or the Internet itself is slow.

The time taken during the Envelope Phase can be reduced by the following steps:
    1) Don't include unnecessary TO, CC, and BCC addresses.  Each address causes your SMTP server to perform a separate DNS look-up (however, one email sent to two addresses is faster than two separate messages).
    2) Identify and remove invalid addresses.  Invalid addresses, particularly those with invalid domains, can result in much longer DNS response times (for example, when a timeout must be detected).
    3) Avoid the "Direct Send" feature.  This adds another DNS look-up for each send in order to find each recipient's SMTP server (however, Direct Send will get each message to its recipient faster since it avoids going through your own SMTP server altogether; "Direct Send" also avoids possible problems with overloading your SMTP server).
    4) Send mail at less busy times of the day when your SMTP server, your company's outside connection, and the Internet itself are not so busy.
    5) Use an SMTP server that is running on a fast machine, has a fast outside Internet connection, has access to fast DNS services, etc.
    6) Use the  multiple sending thread feature of CustomMailer Enterprise Edition.  Using multiple threads can speed up the Envelope Phase considerably and can help overcome all the problems listed above.  The reason is that multiple threads keep your SMTP server busy by letting it work on many DNS requests in parallel instead of waiting for each one to answer back.  This is especially true when you hit a recipient address that results in a long DNS response, because your other threads can keep going even when one thread winds up taking many seconds.

The following things have little effect or no effect on Envelope Phase performance:
    1) The size of your message
    2) The speed of the Internet connection to your SMTP server


Message Phase
During the Message Phase, CustomMailer transmits all the bytes of your message itself to your SMTP server.  The speed of the Message Phase is determined almost entirely by how big your message is and how fast your internet connection to your SMTP server.  A message twice as big will take twice as long to send down the wire no matter what else you do.

The time taken during the Message Phase can be minimized by the following steps:
    1) Reducing the size of your email messages (see next section)
    2) Get a faster Internet connection to your SMTP server
    3) Send mail at less busy times of the day when your SMTP server and the connection to it are not so busy.
    4) Use an SMTP server that is running on a fast machine.

The following things have little or no effect on Message Phase performance:
    1) Reducing the number of TO, CC, and BCC addresses (since only one message is sent regardless)
    2) Having invalid addresses.  The Message Phase is skipped when invalid domains are detected.
    3) Using the "Direct Send" feature.  Of course the various recipient SMTP servers may be faster or slower than yours.
    4) Using multiple threads (since the same total number of bytes needs to be sent down the wire no matter what the order)


Keeping your messages small
Given the speed of your Internet connection, the Message Phase speeds are almost completely determined by the size of your message. Here are some things to think about in order to reduce the size of your message:

Big (= slower)	Small (= faster)
Big messages (every 15 plain text lines = about 1K)	Shorter messages
HTML messages (~25% bigger than equivalent plain text)	Plain text messages
Alternate Text message equivalent to HTML message (nearly doubles size vs. HTML only)	Alternative Text line saying "click here to read message" pointing to a generic message on web server
Self-contained HTML messages with many images and/or sounds (e.g., icon=1K, logo=10K, photo>100K)	HTML images and sounds specified by URLs pointing to copies on your web server
File attachments (can be arbitrarily large)	URLs pointing to downloadable files kept on your web server

 
How many threads should I use?
Clearly related to this question is whether it is worth buying the CustomMailer Enterprise Edition in order to get the ability to use multiple sending threads.  As mentioned above, using multiple threads has a large positive effect on the Envelope Phase and has essentially no effect on the Message Phase.  This means multiple threads can help a lot if and only if you have small messages and a fast Internet connection. If you have big messages or a slow connection, multiple threads are only going to provide a marginal improvement over using a single thread.

To illustrate these points, let's consider the following (oversimplified) performance model.  The Message Phase time is basically proportional to message size (in bytes) and inversely proportional to the speed of your Internet connection (in bytes/second):

    Message Phase time = messageSize / connectionSpeed

The Envelope Phase is a bit trickier to model.  The classic computer science model for performance using multiple processes is governed by "Amdahl's Law" which says that N processes speed up the potentially parallel part of the process by a factor of N, but speed up the serial part not at all.  The resulting equation for the Envelope Phase is:

    Envelope Phase time = envelopeTime / (serialFraction + parallelFraction / numberThreads)

We'll estimate that envelopeTime, which is dominated by DNS look-up speed, averages 1 second (assuming one TO address), though this can be highly variable as mentioned above.  We'll estimate that the serial fraction is 20% and the parallel fraction 80%, corresponding to the non-DNS vs DNS portions of the Envelope Phase, though this is little better than a guess.  Given these assumptions, the following table shows the overall messages per hour (mph) rate and speed up factor using different numbers of threads for different message sizes and different Internet connection speeds:

	1K message size	10K message size	100K message size
10K/sec connection speed (e.g. dial-up)	1 thread: 3273 mph 10 threads: 9474 mph = 2.9X 100 threads: 11688 mph = 3.6X	1 thread: 1800 mph 10 threads: 2813 mph = 1.6X 100 threads: 2980 mph = 1.7X	1 thread: 327 mph 10 threads: 350 mph = 1.07X 100 threads: 353 mph = 1.08X
100K/sec connection speed (e.g. DSL)	1 thread: 3564 mph 10 threads: 12414 mph = 3.5X 100 threads: 16514 mph = 4.6X	1 thread: 3273 mph 10 threads: 9474 mph = 2.9X 100 threads: 11688 mph = 3.6X	1 thread: 1800 mph 10 threads: 2813 mph = 1.6X 100 threads: 2980 mph = 1.7X
1000K/sec connection speed (e.g. T1)	1 thread: 3596 mph 10 threads: 12811 mph = 3.6X 100 threads: 17225 mph = 4.8X	1 thread: 3564 mph 10 threads: 12414 mph = 3.5X 100 threads: 16514 mph = 4.6X	1 thread: 3273 mph 10 threads: 9474 mph = 2.9X 100 threads: 11688 mph = 3.6X

Because of our highly oversimplified model and our crude estimates of quantities like envelopeTime and serial vs parallel fractions, the above message per hour values are for comparison purposes only and should not be used as absolute performance estimates.  But the thread speed-up behaviors predicted by the model are fairly accurate.  The two biggest lessons are:
    1) if you have big messages and a slow connection, multiple threads are going to do little or no good
    2) you get most of the benefit out of having even a modest number of parallel threads (e.g. 10) and diminishing returns thereafter

Regarding the second point, in real world situations, an excessive number of threads can actually be counterproductive because of the associated processing overheads that are introduced.  Ultimately, determining how many threads to use is best determined by direct experience using your system, message content, and mailing lists.


Statistics
To assist in the process of monitoring and tuning performance, CustomMailer provides a statistics display capability.  By selecting the Statistics command under the View menu you can bring up a small window (right) which will show running totals of the number and percentages of messages attempted, successfully sent, duplicates, skipped, opt outs, and in error.  In addition, the processing rate (message sending attempts per hour) and send rate (successful sends per hour) are shown.  These statistics are shown both for the last time the Send button was hit as well as the cumulative totals since this run of CustomMailer began.  The statistics window is a floating window, so you can open it and operate the main CustomMailer window to send email, and watch the statistics update as mail is sent.

A statistics summary is also written to the Send Log file (if enabled) for the entire CustomMailer run upon exit from the program, assuming mail was sent.