30多重の負荷をかけてAPIの性能測定をしていたところ、リクエスト開始から30秒くらい経過した時点でAPIの処理速度が1秒くらい遅延するという怪奇現象が発生しました。
いろいろと調査をしているとPostfixのメール送信のところで急にスローダウンしていることがわかりました。
結果的にパラメータのチューニングを行ったところ処理は改善しましたが、Postfixのデフォルトの設定だといろいろと弊害があるんですね。。。
Postfix チューニング
以下に測定時の環境とチューニング内容を記載します。
性能の測定環境
まず上記図の通り、APIとPostfixは同期的に処理する実装になっていました。なのでPostfixの処理時間がそのまま全体の処理時間に影響してたんですね。ただ、Postfixに対してはメールの送信予約が完了した時点でAPI側に正常応答を返却するので、メール送信処理全体の時間を待つわけではありません。
main.cf パラメータの見直し
何で処理遅延するのだろうか？とPostfixの設定パラメータを１つ１つ調べているとそれらしい記載が
in_flow_delay (デフォルト: 1s)
メッセージ到着速度がメッセージ配送速度を超えた場合に、新しいメッセージを 受ける前に一時停止する時間。この機能はデフォルトで有効になっています (SCO バグのため、SCO UNIX では無効にされています)。デフォルトの 100 SMTP サーバプロセス制限では、”in_flow_delay = 1s” は1秒あたりのメッセージ配送数を超えて入ってくるメールを 毎秒 100 メッセージに制限します。
この機能を無効にするには 0 を指定します。有効な遅延は 0..10 です。
「メッセージ到着速度がメッセージ配送速度を超えた場合に、新しいメッセージを 受ける前に一時停止する時間」
要約すると
負荷をかけすぎてPostfixがメール送信処理予約をキューに溜めこみすぎちゃっていたんですね。
その状況が一定時間続き、ある時閾値を越えた時点で、処理の受付を1秒待つよっていう設定みたいです。
変更後の設定値
なのでこのデフォルトの設定を0に変更してあげれば解決です！
以下のパラメータをmain.cfの末尾に追加してください。
in_flow_delay = 0
変更後に再度性能測定を実施したところ処理遅延は解消されました。
留意点
この設定を入れてしまうと無限にキューに溜めこむことになるため、おそらくディスクがパンパンになります。
その辺はサーバスペックや性能要件と相談しながらチューニングしてみてください。
・設定情報反映コマンドは以下ページを参照
・参考ページ / Postfix 設定パラメータ
コメント