Pleskウェブサーバ

スレッディング・サーバー・モデルとイベント・ドリブン・ホスティング：パフォーマンス・アーキテクチャの比較

スレッディング・サーバー・モデルは、接続ごとにスレッドまたはプロセスを作成します。 イベント・ドリブン 非同期イベントループを持つホスティングは、何千ものリクエストを並行して処理する。私は パフォーマンス レイテンシー、CPU負荷、メモリ要件、および実際のワークロードに基づいて両アーキテクチャを比較することで、お客様のトラフィックとアプリケーションのプロファイルに適したものを、十分な情報に基づいて決定することができます。.

中心点

深く掘り下げる前に、最も重要な発見をコンパクトにまとめ、共通項をすぐに把握できるようにする。パフォーマンス、スケーリング、リソース、そして実践について見ていく。初心者の方でもすぐに理解できるように、またプロフェッショナルの方でも主要な数字を直接分類できるように、あえて分かりやすい表現にしています。以下のキーポイントは、本文中で何度も繰り返し言及する焦点の印である。これを読めば、自分に最も適したセクションを見つけることができるだろう。質問回答があり、あなたの 優先順位 に対処した。.

スケーリング接続ごとのスレッドと、少数のワーカーによるイベントループの比較
レイテンシーコンテキストの切り替えが少なくなり、応答時間が短縮される
リソーススレッド対リーンステートマシンのRAMオーバーヘッド
キャッシングHTTP/3、オペコードとオブジェクト・キャッシュのプッシュイベント・ドリブン
練習方法の選択ブロッキングI/Oのレガシーと、トラフィックの多いCMSやAPIの比較

モデルの仕組み

古典的なモデルでは、入ってくるコネクションごとに別々のスレッドやプロセスを割り当てますが、ApacheではMPMのバリアントであるプレフォーク、ワーカー、イベントによって行われます。 MPMモデルの説明を一緒に使用する。このアロケーションはコネクションをうまく分離し、ブロッキングI/Oを管理しやすくするが、各スレッドには独自のスタック・メモリとスケジューリング・オーバーヘッドがあり、並列度が高いとRAMとCPUを著しく消耗する。このため、並列性が高い場合にはRAMとCPUを著しく消耗する。 イベント・ドリブン 対応するクライアントは、クライアントごとのスレッドを使用せず、ノンブロッキングソケットと、「データ受信」や「ソケット書き込み可能」などのイベントを効率的に分散するイベントループに依存しています。NGINXとLiteSpeedがそのモデルです：ワーカーは何千ものコネクションを並列に管理し、コンテキストの切り替えを減らし、状態をコンパクトに保ちます。州-マシンである。その結果、アーキテクチャーはより軽量に保たれ、特に短時間のリクエストが多数同時に発生するような負荷の下でも、より安定して反応するようになった [3][5][8]。.

リソース消費とレイテンシー

各スレッドは、通常1～8MBの独自のスタック・メモリを必要とし、コンテキスト・スイッチのトリガーとなる。 CPU-これは一般的な設定での実用的な上限を示している[5]。テストでは、Apache のセットアップは約 1,500 の同時リクエスト、210 ms のレスポンスタイム、85 % の CPU 負荷で終わり、これは一般的な構成での実用的な上限を示しています [5]。イベントループは、スレッドの洪水がなく、スケジューラの作業がほとんどないため、かなり少ないRAMで同じスループットを維持します。NGINXは、130ミリ秒、55 % CPUで4,000以上のリクエストを達成しました[5]。LiteSpeedは、統合キャッシュとHTTP/3を使用してTTFBを削減することで、さらに一歩進んでいます。50ミリ秒で10,000以上のリクエストと20 % CPUは、どれだけのオーバーヘッドを排除できるかを示しています[5][8]。私は、これらの違いは構造的なものだと考えています：より少ない コンテキストの変更, ノンブロッキングI/Oと効率的なイベント配信は、レイテンシとエネルギー消費に直接反映される[3]。.

数字で見る直接性能比較

レイテンシー、並列接続、CPU使用率の違いが一目でわかるように、表形式でコアデータを比較している。アーキテクチャーに関する列は、それぞれの設計原則を示すもので、そこから測定結果が導かれる。WordPressのようなCMSを高速化したい場合、イベント駆動型スタックが明らかに有利である。 LiteSpeedとNGINXの比較を照らす。リザーブやボトルネックを早い段階で認識できるため、より現実的に能力を計画するために、私はこれらの値を使用している。この数値は、実験室および実践的な観察に基づくもので、典型的なものをカバーしている。 コンフィギュレーション 今日のホスティング・セットアップの [3][5][8]。.

ウェブサーバー	建築	パラレルリクエスト	応答時間	CPU使用率
アパッチ	マルチスレッド	1.500+	210ミリ秒	85 %
NGINX	イベント・ドリブン	4.000+	130ミリ秒	55 %
ライトスピード	イベント・ドリブン	10.000+	50ミリ秒	20 %

ワークロード・タイプとアプリケーション・シナリオ

静的ファイル、リバースプロキシ・タスク、HTTP/2やHTTP/3の多重化、PHPベースのCMSなど、I/O負荷の高いワークロードでは、ノンブロッキングI/Oのイベントループは、アイドル時間を短縮し、TTFBを短く保つため、顕著な利点を提供する[3][5]。WordPressやWooCommerceのスタックは、キャッシュがより頻繁にヒットし、サーバーの処理時間が短くなるため、恩恵を受ける。 オーバーヘッド これは、コアとなるウェブバイタルをサポートし、検索エンジンのシグナルを安定させる[5]。簡単に非同期化できない長時間実行するブロックタスクがあるレガシーアプリケーションでは、プロセスやスレッドの分離がブロック操作のリスクを軽減するため、Apache workerやpreforkを選択することが多い。高いスループットと多数の同時接続を持つAPIは、特にキープアライブ接続が長続きする場合、イベントドリブンの条件下でその強みを発揮する。負荷プロファイルを正直に測定し、そこからアーキテクチャを導き出すことが重要である。 サンプル を設定する。

プロトコルと接続パターン

HTTP/1.1は、多くの小さなオブジェクトに対して、多数の同時接続に素早く依存する。HTTP/2はTCP接続を介してストリームをバンドルするため、接続のオーバーヘッドを最小限に抑えますが、パケットロスの際にTCPのヘッドオブライン効果に悩まされます。A イベントループ これは、少数のワーカーが多数のソケットのI/Oレディネスを監視するためである [3][5]。HTTP/3(QUIC)は、パケットロスリンク上のTCPの輻輳を排除し、モバイルやWLANリンク上のTTFBをより一定に保つ。イベントドリブンは、WebSocket、サーバ送信イベント、またはgRPC、つまり長寿命の双方向パスに適しています。なぜなら、1つの接続につき数バイトのステータス情報のみが作業メモリに格納され、スケジューラの作業はほとんど必要ないからです。一方、スレッディング・モデルでは、各長寿命コネクションはスタック・メモリで恒久的に「占有」されるため、容量が減少します。.

CPUとプラットフォームの選択

PHPインタプリタや特定のデータベースパスのようなシングルスレッド化が激しいコンポーネントでは、高速なコアがP99のレイテンシを削減するため、高いクロック周波数に注意を払う[1]。L3キャッシュが大きければ、マルチテナント時のRAMアクセスを減らすことができ、P99のレイテンシに間接的に影響します。応答-イベントドリブンのサーバーでは、少数のワーカーが多くのコネクションを管理するため、このメリットがあります。NUMAセットアップでは、ワーカーをノードにバインドして、クロスノードレイテンシとキャッシュミスを回避します。ARMベースのサーバーは、特に、極端なシングルコアのピークを必要としない、多くの並列I/Oイベントを持つワークロードに対して、エネルギー効率の高い代替手段を提供します[9]。両アーキテクチャとも、負荷のピークが スロットル-秤を傾ける。.

イベントループ内の建築ユニット

ほとんどのハイパフォーマンスサーバーは、リアクターパターン（epoll/kqueue）と接続ごとの無駄のないステートマシンを組み合わせている。私はNUMAノードあたりのワーカー数を小さく保ち（多くの場合、ソケットあたり1-2）、以下の方法でスケールします。 ワーカーコネクション, これにより、カーネルはコンテキスト・スイッチの回数を減らすことができる[1][7]。私は、イベントループをブロックしないように、長時間実行するCPU負荷の高いタスクを専用のプロセスやスレッドプールにアウトソースしている。これにより、低いP95/P99値を保証している[3]。HTTP/3では、QUICストリームが帯域幅を公平に共有するように、パケットペーシングオプションをチェックする価値がある[5][8]。このセットアップは、同一のハードウェアの下でイベントドリブンスタックが、より安定したレイテンシで、より多くの同時クライアントを伝送する理由を説明する。.

リソース消費とレイテンシー

OPcacheのようなオペコードキャッシュはPHPの負荷を減らし、RedisやMemcachedは頻繁なオブジェクトアクセスを高速化し、データベースのIOPSを節約する[2][6]。LiteSpeedは統合キャッシュとHTTP/3 [5][8]でこれを強化しています。私はまた、ホットコンテンツがRAMから配信され、ダイナミックパスがよりプレッシャーを感じないように、フロントサイドのHTTPキャッシュを考えています。更新が信頼できるように見えるように、キャッシュの無効化を明確に定義することが重要である。 オブジェクト は行き詰まる。首尾一貫したキャッシング・コンセプトにより、多くのセットアップでサーバーの負荷は半減し、成長段階に必要な容量を確保することができる[2][6]。.

エッジ・キャッシュと再検証

私は、ETag、Cache-Control、„stale-while-revalidate “などのヘッダーとホットルート上のマイクロキャッシュ（0.5-5秒）を組み合わせることで、一貫性を失うことなく負荷のピークを緩和している。アプリケーションレベルでは、正確なキー（ユーザーの役割、言語、通貨など）でキャッシュバスを減らし、不必要なVaryディメンションを避ける。Collapsed forwardingは、多くのクライアントが同じ期限切れのコンテンツを同時にリクエストした場合、オリジンがスタンプされるのを防ぎます。HTTP/3では、接続の確立とロストトレランスが待ち時間のピークを減らすので、これらの対策はさらに強い効果を持ちます。 タイム・ウィンドウ を、より多くの使用可能な容量に直接変換する [5][8]。スレッド環境では、キャッシュヒットがあってもスレッドごとのコストが顕著に残るため、より保守的な計画を立てる。.

マルチスレッド環境のチューニング

RAMやCPUスケジューラーを疲弊させるような、負荷が高い状態でのスレッドの爆発が起きないように、プロセスごとのスレッドの上限を設定している[7]。接続ごとのリソースを節約するためにキープアライブは控えめにし、故障したクライアントがスロットをブロックしないようにハードタイムアウトを定義している。システムレベルでは、クリーンなCPUアフィニティによってコンテキストスイッチを最小化し、影響を受けるコアに近いネットワーク割り込みに優先順位を設定し、近隣の負荷が高い場合にSMTが不利にならないかチェックする。Apacheについては、MPMパラメーターをプロファイルとターゲットレイテンシーに合わせます。スレッドプール最適化. .さらに、私はモニタリングに有意義な情報を提供している。指標 P95/P99のレイテンシー、占有スタックメモリー、エラークラスなど。.

イベント駆動スタックの微調整

ワーカーをNUMAノードにバインドし、物理コアあたりのワーカー数を最適化し、キューを短く保つためにepoll/kqueueパラメータに注意を払う[1][7]。クライアントベースとCDNチェーンがHTTP/3をサポートしていれば、HTTP/3を有効にする。ファイル記述子の制限、ソケットバッファ、カーネルTCPスタックを余裕を持って設定し、多数の同時接続が人工的な天井にぶつからないようにしています。また、LiteSpeedはきめ細かいキャッシュルールとスマートESIの恩恵を受けており、NGINXはホットルートでのマイクロキャッシュで成功しています。イベントレベルでのクリーンなロギングにより、以下のボトルネックが見つかりました。 イベントデバッグのオーバーヘッドを爆発させることなく、-loopを実行する。.

セキュリティ、分離、マルチテナント

共有環境では、プロセスやネームスペースの分離、cgroups、制限付きファイルシステム・ジェイルに頼って、„noisy neighbour “の影響を抑えている。スレッディング・サーバーはプロセスの自然な分離を提供する。断熱, イベントドリブン型サーバは、ワーカーごとの厳しい制限(FD、レート制限、リクエストボディの最大値)とクリーンなバックプレッシャー [3][7]でこれを補います。積極的なヘッダ/ボディのタイムアウトと最小限のバックプレッシャーは、遅い Loris の亜種に対して有効です。 受け入れる-HTTP/2/3では、接続とストリームの制限、優先度ルールを追加しています。アップストリームとCDNが正しく反応するように、429（レート制限）と503（オーバーロード）を明確に区別する。セキュリティスキャンとWAFのルールは、リクエストの優先順位付けやストリームのリセットのようなHTTP/2/3特有のエッジケースが正しく処理されるように、プロトコルに敏感でなければなりません[5]。.

観測可能性とトラブルシューティング

私は各スタックを、アクセプトキューの長さ、アクティブな接続、イベントループの遅延、アップストリームへのキュー時間、1秒あたりのTLSハンドシェイク、エラークラス（4xx/5xx）[1][3]などのチェーンに沿ったメトリクスで計測している。P95/P99を „Time to First Byte “と „Response Complete “に従って分割すると、ネットワーク、アプリ、ストレージのいずれが制限になっているかがわかります。eBPFベースのトレースでは、epoll_wait、TCPの再送、メモリ割り当てなどのカーネルのホットスポットを、大幅に速度を落とすことなく発見できます。スレッド環境では、スタックの使用率やコンテキストスイッチのレートも監視する。イベント駆動型のセットアップでは、ループ内のブロッカー（同期ファイルI/Oなど）や小さすぎるバッファに注意する。コネクションIDやトレースIDを持つログラインは、ウェブ、アプリ、DBビューを接続し、根本原因の分析をスピードアップする[7]。.

コスト、エネルギー、持続可能性

リクエストあたりのCPUワット数は、アーキテクチャーがいかに効率的に電力を使用するかを示す重要な数値であるため、私はこの数値に注目している。イベントドリブン・サーバーは通常、この数値でより良いパフォーマンスを発揮する[3][9]。コンテキスト・スイッチが少なく、メモリ負荷が低いということは、特に冷却システムの稼働が少なくなるため、年間を通じて顕著な節約になることが多い。共有または管理された環境では、同じサーバでより効率的にスケーリングできます。 ハードウェア より多くの並列接続が可能になり、ピークがハードリミットに到達する頻度も低くなります。高いIOPSレートを持つNVMe SSDへの投資は、DBを多用するワークロードにとって特に価値があります。これは、ユーロのコストを削減するだけでなく、キャンペーンの時期や季節に発生するトラフィックのピーク時の可用性を向上させます。.

バックプレッシャー、キュー、テール・レイテンシー

待ち時間Wが一定のサービスレートで増加する場合、同時に待機しているリクエストの数Lは増加します。イベントドリブン・サーバーは、接続あたりのオーバーヘッドがほとんどない [3][5]ので、P99の待ち時間が低下する前に、より高いLに対処することができます。バックプレッシャーの早期のシグナリングは非常に重要である。何分間もリクエストを詰まらせるよりも、429/503をリトライ付きで素早く送る方がよい。レイヤー（イングレス、ウェブ、アプリ、DB）ごとのキューバジェットは、下流のボトルネックがフロントエンドサーバーをオーバーフローするのを防ぎます。イベント駆動スタックでは、ブロッキングパスがループをフリーズさせないように、ハードな非同期制限が必要だ[7]。明確な SLO（例えば、99% < 200 ms）私は、平均値を最適化する代わりに、テール・レイテンシーを積極的に制御している。.

負荷テスト、シナリオ、方法論

クローズド・ループ」（同時実行数固定）と「オープン・ループ」（RPS固定）の両方でテストする。ウォームアップ・フェーズは必須である。キャッシュ、JIT/オペコード、カーネル・バッファが一杯にならなければならないし、そうでなければコールドスタートは誤魔化しになる[1][3]。私は、モバイルの現実をシミュレートするために、ペイロード、キープアライブ時間、HTTP/2/3シェアを変化させ、パケット損失とRTTをシミュレートする。測定変数は、スループット、P50/P95/P99、エラー率、ユーザー/カーネルモードでのCPU時間、コンテキストスイッチ、FD利用率、アップストリームレイテンシーである。重要：PHP/DBパスが支配的であることが多いため、静的ファイルだけでなく、実際のアプリケーションに対するテストを行う。また、accept/SYNのバックログとカーネルのTCP設定（バッファ、リトライ）もチェックし、人為的な上限を測定しないようにしている[7]。こうして得られたプロファイルは、堅実なキャパシティとコストエンジニアリング [3]に反映される。.

移行と互換性の実際

ApacheからNGINXやLiteSpeedに切り替えるときは、機能的なパリティに注意します。.htaccessのルール、動的書き換え、ディレクトリのセマンティクスをきれいに移行する必要があります。PHP-FPMやLSAPIのパラメータ（max_children、プロセス管理）を同時実行ターゲットに合わせて設定し、ウェブサーバーが上流で飢えないようにします。Apacheは内部的にレガシー・ルートを担当し、イベント・ドリブン・プロキシがTLS/HTTP/2/3を終了させ、静的コンテンツと新しいAPIを提供する。これによりリスクを減らし、的を絞った方法で負荷をシフトさせることができる。移行中のモニタリングは、TTFB、エラー率、キャッシュヒット率の低下を早い段階で認識するために必須である[5][8]。最後に、コンフィギュレーションをクリーンアップし、使用していないモジュールを削除し、制限（タイムアウト、ボディサイズ、レート制限）を文書化することで、運用の再現性を維持する。.

プロジェクトフェーズに応じた意思決定支援

トラフィックが不確かなプロジェクトの初期段階では、私はイベント駆動型ホスティングで始めることを好む。長時間実行されるブロック操作の割合が増えたら、私は特にハイブリッドアプローチをチェックするか、高速パスをクリーンな状態に保つためにマルチスレッドサーバーでこれらのパスを分離する。WordPress、WooCommerce、ヘッドレスCMS、多くの並列クライアントを持つAPIについては、レイテンシとスループットがより一定に保たれるため、私は明らかにイベントループのアプローチを推奨する[5][8]。特殊なレガシーアプリケーション断熱また、既知のブロッキングパターンは、RAM予算がスレッドコストを負担する限り、Apache workerやpreforkの方が安全に動作することが多い。本番稼動前に、P95/P99ターゲットと予算や消費電力のバランスをとり、ボトルネックを早期に緩和するために、実際の負荷で各オプションをテストします[1][3]。.

簡単にまとめると

スレッディング・サーバのパラダイムはシンプルな分離を提供し、ブロッキングI/Oをうまく処理しますが、その便利さの代償としてRAMのオーバーヘッドが発生し、コンテキスト・スイッチの回数が増えて遅くなります。 レイテンシー をトップに持ってくる。イベント・ドリブン設計は、わずか数人のワーカーで何千ものコネクションを保持し、特にキャッシュを多用するウェブスタックでは、レイテンシ、CPU負荷、エネルギー効率で得点を稼ぐ[3][5][8]。CMS、API、プロキシにはイベントループを、ハードブロッキングのレガシーにはマルチスレッドアプローチの一部を推奨する。ハードウェアの選択、NUMAバインディング、HTTP/3、一貫性のあるキャッシュは、アーキテクチャに関係なく、顕著にバーを動かす[1][2][6][7][9]。測定値を収集し、ボトルネックを可視化し、的を絞った方法でそれらを切り捨てれば、信頼できる決定を下し、より長期にわたってより良いパフォーマンスを生み出すことができる。 リザーブ 成長のために。.