これは、適切なApache httpd MPMの選択に関する標準的な質問です。
Apacheが提供するさまざまなMPM(「worker」、「event」、「prefork」など)を少し混同しています。
それらの主な違いは何ですか?また、特定の展開に最適なものを決定するにはどうすればよいですか?
これは、適切なApache httpd MPMの選択に関する標準的な質問です。
Apacheが提供するさまざまなMPM(「worker」、「event」、「prefork」など)を少し混同しています。
それらの主な違いは何ですか?また、特定の展開に最適なものを決定するにはどうすればよいですか?
回答:
そこの数あるMPMモジュール(マルチプロセッシングモジュール)が、しかし、これまで最も広く使用されている(少なくとも* nixのプラットフォーム上で)3主なものです:prefork
、worker
、とevent
。基本的に、これらはApache Webサーバーの進化と、長い(ソフトウェア用語で)歴史の計算制約内でHTTP要求を処理するためにサーバーが構築されたさまざまな方法を表します。
prefork
mpm_prefork
ええと...それはすべてと互換性があります。要求を処理するために多数の子プロセスをスピンオフし、子プロセスは一度に1つの要求のみを処理します。サーバープロセスがそこに座ってアクションの準備ができており、スレッドマーシャリングに対処する必要がないため、一度に1つの要求のみを処理する場合、実際には最新のスレッド化されたMPMより高速ですサーバープロセスが解放されるまで順番に待機するようになっているためです。さらに、prefork子プロセスの数を増やしようとすると、深刻なRAMを簡単に消費してしまいます。
スレッドセーフではないモジュールが必要な場合を除き、preforkを使用することはおそらくお勧めできません。
次の場合に使用:のように、スレッドが使用されると壊れるモジュールが必要mod_php
です。それでも、FastCGIとの使用を検討してくださいphp-fpm
。
次の場合は使用しないでください。モジュールがスレッドで破損しない。
worker
mpm_worker
スレッド化を使用します-これは並行性の大きな助けです。ワーカーはいくつかの子プロセスをスピンオフし、子プロセスは子スレッドをスピンオフします。preforkと同様に、着信接続を処理するために、可能であれば予備のスレッドが準備されたままになります。このアプローチはRAM上でより親切です。スレッド数は、プリフォークでのサーバー数のようにメモリ使用に直接影響しないためです。また、接続はpreforkの予備サーバーではなく、フリースレッド(通常は利用可能)を待つだけでよいため、同時実行性もはるかに簡単に処理できます。
次の場合に使用します。Apache2.2または2.4を使用しており、主にSSLを実行している場合。
次の場合は使用しないでください:互換性のためにpreforkが必要な場合を除き、実際に間違いを犯すことはできません。
ただし、トレッドはリクエストではなく接続に接続されていることに注意してください-つまり、キープアライブ接続は、スレッドが閉じられるまで常に保持します(設定によっては時間がかかる場合があります)。だからこそ…
event
mpm_event
構造的にはworkerと非常に似ています。Apache 2.4では、「実験的」状態から「安定的」状態に移行したばかりです。大きな違いは、キープアライブ接続を処理するために専用スレッドを使用し、実際にリクエストが行われたときにのみリクエストを子スレッドに渡すことです(リクエストが完了した直後にそれらのスレッドを解放できるようにします)。これは、一度にすべてがアクティブであるとは限らないが、時々リクエストを行うクライアントの同時実行性、およびクライアントのキープアライブタイムアウトが長い場合に最適です。
ここでの例外はSSL接続の場合です。その場合、ワーカーと同じように動作します(接続が閉じるまで特定の接続を特定のスレッドに接着します)。
次の場合に使用します。Apache2.4を使用しており、スレッドが好きですが、スレッドがアイドル接続を待っているのが嫌いです。誰もがスレッドが好きです!
次の場合は使用しないでください。Apache2.4を使用していない場合、または互換性のためにpreforkが必要な場合。
サーバーへの6つのTCP接続(もちろんキープアライブを使用)を多重化することを好む今日のslowloris、AJAX、およびブラウザの世界では、同時実行性はサーバーを拡張および拡張するための重要な要素です。Apacheの歴史はこの点でそれを束縛しており、リソースの使用量や規模の点ではまだnginxやlighttpdに匹敵するものではありませんが、開発チームがまだ関連性のあるWebサーバーの構築に取り組んでいることは明らかです今日の要求の高い同時実行性の世界で。
The improved connection handling does not yet work for certain connection filters, in particular SSL. For SSL connections, this MPM will fall back to the behaviour of the worker MPM and reserve one worker thread per connection.
これがgifでどのように機能するかの良い説明です:
https://www.datadoghq.com/blog/monitoring-apache-web-server-performance/
簡単に説明すると、2.4でリバースプロキシ(ディスパッチャ)としてhttpdが必要な場合、選択はイベントMPMです
2018年2月の時点で、イベントMPMのApache 2.4ドキュメントでは、Apacheをプロキシとして使用すると、2.4.24以降の「接続処理の改善」が設計どおりに機能しないことが示されています。制限のセクションを参照してください。
問題は、プロキシとして、ワーカーが応答の終わりがどこにあるかを知ることができず、リスナーに制御を返す前に応答全体が見つかるまで待たされることです。
このため、Apacheをプロキシとして使用する場合は、Workerモデルを使用するのが最適であると思われます。プロキシ環境のイベントモデルに利点があるかどうかははっきりしていませんが、おそらくあります。