Research on high availability/scalable SendMail under Linux

Server clusters running SendMail can provide high performance and high availability at competitive prices. This has always been a common practice for experienced system administrators. This article describes our research to quantify and describe ways to achieve highly available/scalable sendmail.

We studied several configurations of SendMail clusters on Linux and quantified their relative performance. We have studied and tested public performance by adjusting the configuration of Sendmail and the parameters in the Linux operating system. We don't have a shared disk for these tests, so we limit the scope of the project to include only SMTP routing and queuing. This is a common configuration for SendMail clusters located at the edge of a private network or as a front-end for internal mail storage.

Although our hardware resources are common, we believe that these relative differences will make our results very important for system architects who want to implement Linux based sendmail server clusters, as our results illustrate the relative importance of the design characteristics of the SendMail cluster.

Summary results

Sendmail, LDAP, and DNS have many configuration options, but we consider only those options that are important to the application. Unless otherwise stated, we use standard software and default settings. Among these options, we find that there are a few factors that can have a significant impact on performance or that are essential to achieving scalability, such as LogLevel and QueueDirectory.

Finally, we find that even if Sendmail is properly configured, all these important factors will tell us two facts:

Sendmail is disk-intensive, the faster the disk speed, the faster the Sendmail speed.

Uncontrolled factors may affect the performance we perceive. For example, a remote DNS server fails, routes are out of order, queues fill up, and other third-party issues.

What did we find?

Clustered servers: We found the best message throughput-approximately 100 messages per second-by clustering two servers and adding load balancers to the front end. This is twice times the performance of the best single server result, and the best performance for a single server is approximately 50 messages per second. When you add a third server, you can hardly see any improvement in performance.