MTA のパフォーマンスは、次の項目を含む多くの要素に影響されます。
ディスクパフォーマンス
SSL の使用
インバウンドおよびアウトバウンドのメッセージ数および接続数
メッセージのサイズ
対象送信先数およびメッセージ数
MTA との接続スピードと接続待ち時間
スパムフィルタリングまたはウィルスフィルタリングの必要性
SIEVE 規則とその他のメッセージ解析 (変換チャネルの使用など) の使用
MTA は CPU と入出力を集中的に使用します。MTA は、キューディレクトリとロギングディレクトリという異なる 2 つのディレクトリに対し、読み書きを行います。MTA として機能する小規模なホスト (4 プロセッサ以下) では、これらのディレクトリを別のファイルシステムに分ける必要はありません。キューディレクトリでは、かなり大きい量で同期書き込みが行われます。ログディレクトリでは、小さな量の非同期書き込みが連続的に行われます。トラフィック量の多いシステム上では、これら 2 つのディレクトリを分離し、それぞれ異なるファイルシステム上に配置することを検討してください。
ほとんどのケースで、ディスクサブシステムの MTA で冗長性を導入して、ディスクの障害時にメールデータが永久に失われることを回避したいと考えるでしょう。ディスクの障害は、ハードウェアの障害で最も起こる可能性の高いものです。これは、多くの内部ディスクを持つ外部ディスクアレイやシステムが最適だということを意味します。
外部 RAID コントローラデバイスとソフトウェアミラーによる JBOD アレイの使用との間にはトレードオフの関係があります。JBOD によるアプローチは、ハードウェアの購入という点では安価な場合がありますが、より多くのラックスペースと電力を必要とします。JBOD アプローチは、ソフトウェアによるミラーリングを行うことでサーバーのパフォーマンスを少し低下させ、一般的には保守コストも高くなります。ソフトウェア RAID5 は、パフォーマンスへの影響が非常に大きいため、代わりに使うことができません。そのため、RAID5 を使用する場合は、RAID5 キャッシングコントローラアレイを使用します。
MTA の処理能力は 8 プロセッサを超えても直線的に向上します。また、メッセージストアと同様に、1 プロセッサから 4 プロセッサまでは飛躍的にアップします。
MTA を HA の制御のもとに置くのはあまりお勧めできません。しかし、それが保証されている環境では例外です。ハードウェアの障害時にも、メールの配信を短時間で指定した時間枠内で実行しなければならないという要件がある場合は、MTA を HA のソフトウェア制御のもとに配置します。ほとんどの環境では、ピーク負荷要件に対応できるように MTA の数を単純にいくつか増やします。これにより、1 つの MTA で障害が発生した場合でも、または大規模な配備環境で何らかの理由で複数の MTA の接続が遮断された場合でも、適切なトラフィックフローが生み出されます。
さらに、MTA の配置に関しては、MTA を常にファイアウォールの内側に配置するよう配慮します。