Pleskウェブサーバ

Apache Event MPM 対 Worker MPM：高負荷に対応する最新のWebサーバー・ターボ

なぜその選択が適切なのかを、2つの文で説明します。 Apache MPM 高負荷下におけるスループット、レイテンシ、安定性に目に見える影響を与えます。ここでは、特に長期のキープアライブ接続、HTTP/2、および高い並列処理において、Event MPMとWorker MPMを具体的に比較し、そこから明確なチューニングの推奨事項を導き出します。.

中心点

重要なポイントをすぐに把握できるよう、核心となる内容を簡潔にまとめ、重要なキーワードを太字で強調します。これらのポイントをもとに、後ほど具体的な操作手順や設定方法を導き出し、実用的な観点から解説します。両方のMPMについて、多数の接続を含む現実的な負荷プロファイルの下で一貫して評価を行います。これにより、どのモジュールがスタックの中で際立っているかを、回り道することなく把握できます。このリストは、日々の運用において確かな判断を下すための近道となります。.

イベント Idle-Keep-Aliveをリクエストスレッドから切り離し、接続数が多い場合でもスケーラビリティを確保します。.
労働者 短いリクエストでは有利ですが、キープアライブ時間が長いとスレッドを消費してしまいます。.
HTTP/2 効率的なマルチプレクシング処理により、イベントから明確なメリットを得ています。.
リソース: このイベントにより、アクティブなリクエスト1件あたりのRAM/CPU使用量が抑えられます。.
互換性: スレッドセーフなモジュールは必須であり、mod_phpは引き続きプレフォーク方式の領域にとどまる。.

なぜ「ワーカー」と「イベント」が主流となっているのか

私は現代の企業運営において、明確に以下を重視しています スレッド, 、というのも、プロセスに比べて接続1つあたりのRAM使用量が少ないからです。Preforkはかつて、スレッドセーフでないモジュールでも安定性を提供していましたが、接続数が増えるとスケーラビリティが低下します。現在では、多数の同時ユーザーを適切に処理できる「ワーカー」と「イベント」方式が主流となっている。これは、接続が長時間開いたままになるアクティブなキープアライブやHTTP/2において、特にその真価を発揮する。まさにそこが イベント その強みは、アイドル状態の接続を貴重なリクエストスレッドに割り当てない点にある。.

Apache Worker MPM：アーキテクチャと制限事項

私は、ワーカーをプロセスと スレッド, 、各子プロセスが1つのリスナースレッドと多数のサーバースレッドを持つ仕組みです。リクエストはスレッドに割り当てられ、応答が返されると、そのスレッドは解放されます。接続がオープンされたままの場合、同じスレッドがその接続にバインドされたままになります。これにより、多くのクライアントが長時間待機したり、散発的に小さなリクエストを送信したりする場合、アイドル状態が発生します。したがって、ワーカーを使用する場合は、スレッドプールと制限を適切に設計する必要があります。そのための参考として、私の短いスレッドプールの最適化出発点として用いる。.

Apache Event MPM：イベントループの解説

私はイベントを「ワーカー＋イベントループ」として説明しています。つまり、 リスナー-アイドル状態の接続を保留するスレッド。リスナーは新しい接続を受け付け、アクティブなリクエストを空きのあるワーカースレッドに渡した後、その接続を解放します。これにより、リクエストスレッドはデータが流れるときのみ動作することになります。そのため、スレッドをブロックすることなく、数百から数千ものクライアント接続を維持することが可能です。まさにこの駐車これにより、典型的なHTTP/1.1およびHTTP/2のワークロードにおいて、Eventの効率が向上します。.

イベント対ワーカー：負荷がかかった際の違い

私は常に両方のMPMを実際の状況に基づいて評価しています負荷キープアライブ時間が長い場合。アイドル状態の接続がスレッドを占有してしまうため、ワーカーはすぐに上限に達し、その結果、新しいリクエストを処理するためのスレッドが不足してしまいます。イベント処理はスレッドプールを解放し、アイドル状態の接続をイベントループに送り込みます。これにより、レイテンシを安定させたまま、同時に処理できるユーザー数を大幅に増やすことができます。判断材料が必要な場合は、具体的な事例を比較検討することをお勧めします。イベント駆動型サーバーモデル負荷テストにおけるスレッドプールについて。.

互換性：モジュールと代表的な構成

最初にチェックするのは モジュール, 、というのも、ワーカーとイベントはスレッドセーフであることが求められるからです。従来の mod_php スタックはこれに適合しないため、ここでは依然としてプレフォークが理にかなっています。一方、PHP が PHP-FPM や FastCGI 経由で実行される場合は、迷わずイベントを選択します。これは、アプリケーションサーバー、マイクロサービス、あるいはGo/Nodeバックエンドへのリバースプロキシについても同様です。このような構成では、Worker、とりわけ イベント 互換性を一切損なうことなく、その強みを発揮します。.

設定：主要なディレクティブ

主要な指針を簡潔に紹介するので、それらを確実に理解し、特注. MaxRequestWorkers は、同時に処理されるリクエストの数を制限します。Event の場合、アイドル状態の接続が処理を妨げないため、この値を高く設定できることがよくあります。ThreadsPerChild は、プロセスごとのスレッド数を定義します。少なすぎるとスループットが低下し、多すぎると CPU に負荷がかかります。 ServerLimitはプロセスの上限を設定し、それによってクラスタ全体での並列リクエストの上限を決定します。KeepAliveTimeoutでは、接続が維持される時間を制御します。この値が高いほど、その恩恵は大きくなります。 イベント.

表による比較：ワーカー対イベント

主な特徴を簡潔にまとめると、 テーブル 違いが一目でわかるようにまとめました。これは負荷テストの代わりにはなりませんが、重要な特徴を体系的に把握するのに役立ちます。項目を左から右へと読み進め、自社のトラフィックプロファイルに照らし合わせてみてください。そうすることで、自社のアーキテクチャに適したMPMを素早く見つけることができます。焦点は、スケーラビリティ、リソース要件、および以下の状況下での挙動に明確に置かれています。 キープアライブ.

基準	Worker MPM	イベントMPM	影響
キープアライブ処理	スレッドは接続に紐付けられたままになる	アイドル状態の接続は、イベントループによって保留される	イベントはリクエストスレッドを解放したままにする
資源の活用	アイドル時のバインドスレッドの増加	アイドル時のスレッドの占有数が減少	アクティブなリクエスト1件あたりのRAM/CPU使用量が少ない
負荷時のレイテンシー	もっと早く出発する	より長く安定した状態を保つ	応答性の向上
HTTP/2 対応	きちんとした	非常に効率的	多重化のメリット
構成	MaxRequestWorkers、ThreadsPerChild、ServerLimit	即時処理、およびイベントループの最適化	イベントにより稼働率の向上が可能
互換性	スレッドセーフなモジュールが必要	同様に、PHP-FPMの使用が推奨されます	Preforkはmod_phpのオプションのまま

実践：チューニングのワークフローと測定

私はいつも、クリーンなベースラインから始めるようにしています モニタリング およびログデータ。その後、MaxRequestWorkers と ThreadsPerChild を段階的に変更し、レイテンシ、エラー率、CPU 負荷を測定します。KeepAliveTimeout は、理想的な時間がクライアントの挙動に大きく左右されるため、段階的にテストします。この段階からは、ab、wrk、JMeterなどのツールを使用して、EventとWorkerの比較を行う価値があります。メトリクスが良好な状態になって初めて、 プロフィール そして、主要指標を記録する。.

Preforkが依然として有効な場合

スレッドセーフでないことが絶対条件の場合、私はPreforkを利用します。 モジュール 実行する必要がある。その場合、プロセスごとの分離がスケーラビリティよりも重要になる。その代償として、接続1件あたりのRAM使用量が大幅に増えることは容認する。カスタマイズが不可能なレガシーアプリケーションの場合、これが現実的な選択肢となることが多い。しかし、PHP-FPMやその他の外部アプリケーションサーバーを使用する場合は、 イベント はっきりと。.

ウェブホスティングの背景とプロバイダーの選び方

ホスティング環境では、1台のサーバーに多くの仮想ホストが配置されることが多いため、MPMプロファイルに注意を払っています走る. Eventは、特にHTTP/2やTLSと組み合わせることで、リソースを最も効率的に活用できます。私のスタックでPHP-FPMが必要な場合は、Eventをデフォルトに設定します。概要や技術的な確認には、以下の簡単な解説が参考になります。 Prefork、Worker、Eventの比較最終選考の前に。この課題をこなせば、明らかに良い結果が得られる 応答時間 1ユーロあたり。.

ベスト・プラクティス・コンパクト

私は一貫して利用しています ピーエッチピーエフピーエム あるいは他の外部アプリサーバーと連携させ、Eventがそのポテンシャルを最大限に発揮できるようにします。その後、MaxRequestWorkersとThreadsPerChildをCPUコア数とRAM容量に合わせて調整し、システムのハードリミットを確認します。アイドル状態のクライアントが多い場合は、Eventを選択し、KeepAliveTimeoutを意図的に高く設定して、レイテンシを監視します。リクエストが非常に短く、キープアライブが適度なワークロードの場合、モジュールがスレッドセーフであれば、Workerで十分です。スレッドの使用率、エラー、および 遅延時間 最終的な決定はしません。.

イベントおよびワーカーの具体的な設定例

私は2つのミニマルなプロファイルを用意し、それを出発点として、測定値に基づいて微調整を行います。重要な点は： MaxRequestWorkers = ServerLimit × ThreadsPerChild. RAMの割り当て量とスレッドごとの必要量（モジュール、TLS、バッファを含む）から逆算し、段階的に増やしていきます。.

# の例：Event MPM（HTTP/2、PHP-FPM）
ServerLimit 16
ThreadLimit 256
ThreadsPerChild 64
MaxRequestWorkers     1024
StartServers 4
MaxConnectionsPerChild 10000

KeepAlive On
MaxKeepAliveRequests  100
KeepAliveTimeout 15

# オプション設定。測定結果に基づいて調整してください：
# ListenBacklog 1024
# ThreadStackSize     1048576   # 1 MB、モジュールが許可する場合のみ
# AsyncRequestWorkerFactor 2    # イベントループの微調整、通常はデフォルトのまま

# HTTP/2
Protocols h2 http/1.1
# H2MaxSessionStreams  100-200  # バックエンドの処理能力に応じて微調整する

# の例：ワーカー MPM（短いリクエスト、適度なキープアライブ）
ServerLimit 8
ThreadLimit 256
ThreadsPerChild 50
MaxRequestWorkers     400
StartServers 4
MaxConnectionsPerChild 5000

KeepAlive On
MaxKeepAliveRequests  100
KeepAliveTimeout 3
Protocols http/1.1

持っている MaxConnectionsPerChild (別名：MaxRequestsPerChild) を 0 以外にすることで、徐々に進行するメモリリークを検出できるようにする。. KeepAliveTimeout Eventでは、アイドル状態の接続はコストが安いため、意図的にこの値を高く設定しています。一方、Workerでは、スレッドがブロックされないように、この値を低く設定しています。.

Event を使った HTTP/2 の微調整

私は以下の点に留意しています HTTP/2, 、ブラウザは接続をほとんど開かず、多くの ストリーム マルチプレックス化。これにより、ボトルネックが接続数から、公平なスレッド割り当てやバックエンドの処理能力へと移行します。Event を使用すると、ストリームが待機している間はスレッドが空き状態のままとなるため、レイテンシのピークが平滑化されます。実用的な調整手段：

H2MaxSessionStreams: 通常、50～200の範囲で設定しています。高すぎるとバックエンドでヘッド・オブ・ライン効果が生じ、低すぎると並列処理の効率が低下してしまいます。.
最大リクエストワーカー数: イベント処理では、RAMとCPUの処理能力が許す限り、処理レベルを上げることができます。並列処理の度合いが高まるにつれて、レイテンシの95パーセンタイルおよび99パーセンタイルを監視しています。.
ティーエルエス: ALPNと最新の暗号スイートを活用することで、ハンドシェイクのオーバーヘッドを低減しています。さらに、ストリームバースト間のアイドルフェーズを効率的に保留できるため、イベントにもメリットがあります。.

OSの制限とソケットのバックログ

負荷テストを行う前には必ずシステムの限界を確認しています。そうしないと、MPMではなくカーネルによって制限されてしまいます。接続数が多い場合は、特に以下の点をスケーリングしています：

ファイル記述子: ulimit -n と systemd リミットNOFILE 例えば、65536以上などに増やします。Apacheは、ソケット、ログ、パイプごとにFDを必要とします。.
バックログ: net.core.somaxconn そして tcp_max_syn_backlog Acceptキューがオーバーフローしないように、適切な値（例：1024～4096）を設定します。.
ポート範囲 （リバースプロキシの場合）： ip_local_port_range バックエンドへの同時アウトバウンド接続数が多い場合は、この範囲（例：10000～65000）に設定します。.
FIN/タイムアウト: 以下の点に注意してください tcp_fin_timeout: 設定が過度にアグレッシブだと接続が切断される可能性があるため、測定基準に基づいてのみ変更しています。.

私はカーネルの調整をすべて、その理由とともに記録し、再度負荷測定を行って検証しています。検証結果が得られない限り、デフォルト設定が正しい場合がほとんどです。.

日常業務における監視とトラブルシューティング

起動させる 拡張ステータス そして、server-status を使って、 スコアボード-の状態を読み取る。イベントでは、ワーカースレッドがフル稼働していないにもかかわらず、多くのアイドル／キープアライブソケットが見られる。エラーログに「server reached」と表示される 最大リクエストワーカー数 「setting, consider raising the MaxRequestWorkers setting」というメッセージが表示された時点で、サーバーはすでに限界に達しています。慎重に値を増やしながら、RAMやCPUの使用状況、およびエラー発生率を監視しています。.

測定範囲: アクセスログには、応答時間（例：%D/%T）、ステータスコード、バイト数を記録しており、ピーク値をCPU/IOと照合しています。.
ワーカーに見られる症状: 多くのキープアライブ接続が非アクティブ、スレッドが100 %で占有され、レイテンシが増加、503/504エラーが発生――スレッドが占有されている兆候。.
イベント時の症状: リスナースレッドの負荷が高いが、ワーカースレッドには余裕がある――これはたいていネットワークやバックエンドのボトルネックによるもので、MPMの問題ではない。.
Graceful-Reload: 変更を反映して apachectl -k graceful 既存の接続から水がきれいに流れ出るようにするためです。.

キャパシティプランニング：コアとRAMからMaxRequestWorkersまで

私は実用的な観点から計算します。スレッド1つあたり、バッファを含めてどの程度のRAMを割り当てるか？ TLS、フィルタ、一般的なモジュールを考慮して、スレッド1つあたり数MBという控えめな数値で計算します。そして、次のように設定します。 最大リクエストワーカー数 これにより、スワップなしで95パーセンタイルおよび99パーセンタイルのピーク負荷を処理できるようになります。CPUレベルでは、コア数を超えるスレッドは、常に実行時間が長い処理を行っていない限り、効果を発揮します。イベント処理に関しては、アイドル状態のコストがほとんどないため、より高い値を設定しても問題ありません。.

大まかな目安: まず、プロセスあたり32～64スレッド、4～16プロセスで開始し、その後、測定と調整を行う。.
スレッドスタックサイズ: RAMが不足していて、モジュールの仕様上可能であれば、スタックサイズを縮小します（ストレステストを行いながら慎重に）。.
MaxKeepAliveRequests: 私はたいていデフォルトの設定のままにしていますが、通信量の多いクライアントの場合、値を大きくするとオーバーヘッドを軽減できることがあります。.

リバースプロキシのシナリオとバックエンド接続

私は特にアプリのバックエンドにEventを活用するのが好きです。なぜなら、 フロントエンドソケット 効率的に駐車させ、実際の処理はバックエンドで行われます。そこで重要なのは、 バックエンド接続 (mod_proxy):

バックエンドへのキープアライブ: ハンドシェイクを節約するために有効のままにしておく；プールのサイズ（max （各ターゲットごとに）バックエンドの処理能力に合わせて選択してください。.
プロキシのタイムアウト: タイムアウトを明確に定義し、応答しなくなったバックエンドがフロントエンドのスレッドを占有しないようにする。.
バックエンドへのHTTP/2: 可能な限り、H2（例：内部ではh2c）を使用して、接続数を減らしながらストリーム数を増やしています。Eventはこの方式と相性が良いです。.

フロントエンドとバックエンドのレイテンシの割合を重点的に監視しています。バックエンドの処理時間だけが伸びている場合、MPMのチューニングだけでは解決できません。その場合は、プールサイズ、タイムアウト、またはバックエンドのリソースを調整する必要があります。.

ロールアウト戦略と、ワーカーからイベントへの移行

私は明確な手順に従って移行を進めています。まず、 モジュール一覧 (apachectl -M) を使用してスレッドセーフ性を確認します。スレッドセーフでないもの（従来の mod_php など）はすべて削除するか、隔離する必要があります。その後、Event を有効にし、控えめな初期値を設定して、ステージング環境で負荷テストを実行します。本番環境への展開では、まずトラフィックの一部（カナリア）から開始し、メトリクスを比較した上で、その後で本格的に展開を行います。.

コマンド: ディストリビューションの標準的な手順に従い、MPMモジュールを切り替え（例：a2dismod/a2enmod）、正常に再起動してください。.
代替案: 「Event」モジュールで何か異常な動作が見られた場合に備えて、ワーカープロファイルを準備しています。.
ドキュメンテーション: 制限値、HTTP/2パラメータ、カーネル設定値の変更については、変更前後の測定結果をすべて記録しています。.

セキュリティとTLSのパフォーマンスに注目

TLSに関しては、ハンドシェイクがCPU負荷が高く、負荷がかかるとレイテンシが増加する可能性があることに留意しています。 セッション再開 また、最新の暗号アルゴリズムを選択することでコストを削減しつつ、アイドル状態のフェーズを効率的に保留します。HTTP/2およびALPNと組み合わせることで、余分なラウンドトリップを回避します。重要：TLSバッファとOpenSSLパラメータは、スレッドごとのRAM使用量に含まれるため、容量計画においてこれらを考慮に入れています。.

フォールトトレランスとグレースフル・ディグラデーション

オーバーロードに備えて計画を立てています：CPUが飽和状態にあるか、あるいはApacheが 最大リクエストワーカー数, 、リトライが雪だるま式に増えるのは避けたい。明確なタイムアウトを設定し、分かりやすいエラーページを用意し、上流のプロキシにレート制限を設ける。イベントを活用すれば、プレッシャーがかかっている状況でもより多くの スレッド 実際の処理に割り当てられるリソースを確保しつつ、アイドル状態の接続は保留状態にしておく――まさにこの予備リソースがあるからこそ、負荷が再び低下するか、自動スケーリングが作動するまで、システムを長く稼働させ続けることができるのです。.

簡単にまとめると

今日の業務では、私は以下を重視しています イベント, スタックがスレッドセーフなモジュールとPHP-FPMを使用するようになれば。このアプローチにより、アイドル状態の接続における占有スレッド数が削減され、応答時間が安定し、並行して処理できるユーザー数が増加します。組織上の理由でEventが適さない場合、短時間のリクエストでキープアライブが中程度であれば、Workerは依然として堅実な選択肢となります。Preforkは、スレッドセーフでないモジュールや古いコードを使用する環境のために取っておきます。明確な負荷テスト、ディレクティブの適切なチューニング、そして可視化された モニタリング Apacheを再現性のある形で最高回転数まで引き上げます。.