MTA Performance Considerations

MTA performance is
affected by a number of factors including, but not limited to:

Disk performance

Use of SSL

The number of messages/connections inbound and outbound

The size of messages

The number of target destinations/messages

The speed and latency of connections to and from the MTA

The need to do spam or virus filtering

The use of Sieve rules and the need to do other message parsing
(like use of the conversion channel)

The MTA is both CPU and I/O intensive. The MTA reads from and writes
to two different directories: the queue directory and the logging directory.
For a small host (four processors or less) functioning as an MTA, you do not
need to separate these directories on different file systems. The queue directory
is written to synchronously with fairly large writes. The logging directory
is a series of smaller asynchronous and sequential writes. On systems that
experience high traffic, consider separating these two directories onto two
different file systems.

In most cases, you will want to plan for redundancy in the MTA in the
disk subsystem to avoid permanent loss of mail in the event of a spindle failure.
(A spindle failure is by far the single most likely hardware failure.) This
implies that either an external disk array or a system with many internal
spindles is optimal.

MTA and RAID Trade-offs

There are trade-offs between using external hardware RAID controller
devices and using JBOD arrays with software mirroring. The JBOD approach is
sometimes less expensive in terms of hardware purchase but always requires
more rack space and power. The JBOD approach also marginally decreases server
performance, because of the cost of doing the mirroring in software, and usually
implies a higher maintenance cost. Software RAID5 has such an impact on performance
that it is not a viable alternative. For these reasons, use RAID5 caching
controller arrays if RAID5 is preferred.

MTA and Processor Scalability

The MTA does scale linearly beyond eight processors, and like the Message
Store, more than linearly from one processor to four.

MTA and High Availability

It is rarely advisable to put the MTA under HA control, but there are
exceptional circumstances where this is warranted. If you have a requirement
that mail delivery happens in a short, specified time frame, even in the event
of hardware failure, then the MTA must be put under HA software control. In
most environments, simply increase the number of MTAs that are available by
one or more over the peak load requirement. This ensures that proper traffic
flow can occur even with a single MTA failure, or in very large environments,
when multiple MTAs are offline for some reason.

In addition, with respect to placement of MTAs, you should always deploy
the MTA inside your firewall.