1.5 Tuning Isn t Always Necessary

1.5 Tuning Isn't Always Necessary

While this book focuses on email tuning, a large percentage of email systems on the Internet today simply don't deal with enough traffic to justify buying expensive hardware and spending a great deal of time tuning applications to handle their load. This statement doesn't mean that email performance tuning won't offer any benefit for these systems, but merely that extreme measures aren't justified. This section aims to identify the thresholds at which the most naive email server implementation is likely although not guaranteed to work just fine. Typically, storage I/O speeds limit email server performance, as we shall see. In the scenarios that follow, however, we assume that each server in question has a sufficiently fast I/O system such that it can move data near the maximum capability of its CPU, memory, and networking subsystems.

The first scenario under which no email server tuning is likely to be necessary is if a site's Internet connection is limited to T1 (1.544 Mbps) or lower speeds. Even obsolete computers, such as the Sparc Station 2 (circa 1991 for readers who may only have encountered these machines in history books) or any PC with an Intel 80486 or equivalent chip, can easily saturate a T1 line if it does not attempt to perform complex computations on all data that flow through it. If a site sends a majority of its email to and from the Internet (rather than within the organization), and the corporate Internet connection is a T1, then a single Sparc 2 would probably perform admirably as a corporate mail gateway server. If it doesn't and the email server slows down, the true source of the problem likely isn't the server. Rather, the network is probably the culprit.

A low-end Pentium box (with a capable networking card, a description fitting all the cards currently on the market) can easily saturate a 10 Mbps Ethernet segment with unfiltered traffic and, even if performing significant stateful modification of the packets, can saturate a T1 with very little difficulty. A Pentium II box, any UltraSparc, or any system based on an Alpha chip can easily saturate a 10 Mbps Ethernet while substantially modifying incoming data. Further, almost any server based on these processors can quite easily pass 100 Mbps of raw data through it if its networking is adequate. A four-processor Sun E420R, or equivalent server from another vendor, with a high-quality, well-tuned storage system acting as an email hub, can process in excess of 100 Mbps of email traffic (SMTP and POP). It makes no sense to purchase such a powerful server, tune it, and then have it serve email via a 10 Mbps network. As a corollary, if email traffic peaks at or around 10 Mbps, that site would waste its money by buying a multi-CPU machine, even if the vendor classifies it as a "workgroup server."

Before anyone can object to the veracity of the numbers cited here, let me state that these are rough rules of thumb. These figures are drawn from personal experience with real loads using commonly available software to handle Internet traffic. While research projects have driven 100 Mbps networks to capacity with low-end processors using specially written software, that case isn't of particular interest here. On another note, while this book discusses tuning email systems, it will only occasionally discuss tuning the source code of the email applications themselves.

Often, those intending to send large quantities of email during the course of a day greatly overestimate the resources needed to accomplish this task. Sending 1 million email messages in a 24-hour period sounds like a much more tractable problem if it is restated as sending a little less than 12 messages/second. If the message body remains the same in all cases and is short and stored in one place (so that it can be held in memory), such as might be the case on a mailing list server, generating messages at this rate is not at all difficult. Even the network bandwidth isn't difficult to handle. If each message is 10KB in size, and no optimization can be achieved by sending the same message to multiple recipients at the same site through a shared connection, at 12 messages/second this case involves only 1 Mbps of network traffic (just counting the message data itself). Of course, this scenario doesn't consider packet overhead, DNS requests, the potential for ICMP traffic, and traffic used in failed transmission attempts. Nevertheless, if this is the sum of the network traffic consumed and either the load is well spread out over the day or modest delays in email sent at peak times are acceptable, then a single T1 line would suffice to accommodate this load. As we have seen, it doesn't take a particularly beefy machine by today's standards to fill a T1 with email. In fact, the only likely performance problem in this scenario involves how to deal with messages that aren't deliverable in the first pass as they back up in the queue. If 1 out of every 100 of these 1 million messages are undeliverable for a day, the average number of messages in the queue will be 10,000 entries, a large enough number to significantly slow down filesystem access.

In any case, these sorts of numbers lie at the heart of building powerful email systems. The more information available on how the system will behave, the more accurately one can forecast the resources needed to get the job done.