In addition to our standard suite of web application testing services, Web Performance can also load test mail servers. In this post, I’ll describe what email load testing is, why it should be done, and how we do it.
Mail servers can be load tested by sending a large number of emails to a mail server over a specific period of time and recording how the server behaves as it receives those connections. Organizations may require this type of load testing for several reasons. For example, they generally receive a consistent, low level of mail traffic with intermittent periods of high traffic. They may also expect growth within a certain period of time and want a mail server that is capable of scaling with the organization’s growth.
This type of testing can help an organization understand and prepare for either situation. Specifically, testing may reveal:
The following graphic represents the mail server load testing process:
As shown above, we perform testing using several Amazon mail servers in various geographical locations (US-East and US-West in the example above).
The Email Test Controller coordinates with these servers to send a large number of pre-generated emails over a set period of time to the specified mail server. In addition to using servers in different physical locations, we create emails from numerous templates containing rich HTML and embedded images. These characteristics enable our load testing to more realistically simulate actual emails.
Additionally, the Web Test Controller measures the responsiveness of the webmail interface as emails come in.
The image below shows which variables are tracked during a load test. Specifically, we track the number of emails sent and received, the time between sending and receiving emails, and whether or not the server rejects or bounces back any messages:
As a result of this test, we see that this mail server received all messages delivered by our system. We also see that while the bulk of the messages were received within 11 minutes, the mail server began to exhibit some lag and messages began to queue up, with the mail server only receiving 100% after 21 minutes had passed.
Additionally, by tracking both the amount of mail sent and received, we can identify which messages were rejected or undeliverable, and why. In one instance, for example, testing revealed that an organization’s spam filter was rejecting emails containing non-ASCII characters. By identifying these issues, the mail server can be reconfigured to let these messages through.
Founder of Web Performance, Inc
B.S. Electrical & Computer Engineering
The Ohio State University
LinkedIn Profile