Nginxが数万のコンカレントに簡単に到達できるのはなぜですか？

Nginxは、その高性能、安定性、豊富な機能、シンプルな構成、および低リソース消費で知られています。この記事は、なぜNginxがそんなに速いのかを理解し ています！

Nginxプロセスモデル

Nginxサーバー、通常の操作時：

マルチプロセス： 1つのマスタープロセス、複数のワーカープロセス。
マスタープロセス：ワーカープロセスを管理します。外部インターフェイス：外部操作（信号）の受信、内部転送：さまざまな外部操作に応じて、信号を通じてワーカーを管理します。監視：ワーカープロセスの実行ステータスを監視し、異常終了後にワーカープロセスを自動的に再起動します。
ワーカープロセス：すべてのワーカープロセスは同等です。実際の処理：ネットワーク要求はワーカープロセスによって処理されます。ワーカープロセス番号： nginx.confで設定され、通常はCPUリソースを最大限に活用するためのコア数に設定されます。同時に、過剰なプロセス数を避け、CPUリソースの競合を避け、コンテキストスイッチングの損失を増やします。

HTTP接続の確立と要求の処理

HTTP接続の確立と要求の処理プロセスは次のとおりです。

Nginxが起動すると、マスタープロセスが構成ファイルをロードします。
マスタープロセスはリスニングソケットを初期化します。
マスタープロセスであるForkは複数のワーカープロセスを生成します。
ワーカープロセスは新しい接続を求めて競合し、勝者は3ウェイハンドシェイクを介してソケット接続を確立し、要求を処理します。

Nginxの高いパフォーマンス、高い同時実行性

Nginxのパフォーマンスが高く、高い同時実行性をサポートできるのはなぜですか？

Nginxはマルチプロセス+非同期非ブロッキングモード（IO多重化Epoll）を使用します。
リクエストの完全なプロセス：接続の確立→リクエストの読み取り→リクエストの解決→リクエストの処理→リクエストへの応答。
完全な要求プロセスは、最下層のソケットイベントの読み取りと書き込みに対応します。

Nginxイベント処理モデル

リクエスト：NginxのHTTPリクエスト。

基本的なHTTP Webサーバーの動作モード：

リクエスト受信：リクエストラインとリクエストヘッダーを1行ずつ読み、セグメントにリクエストボディがあると判断した後、リクエストボディを読みます。
リクエストを処理します。
レスポンスを返す：処理結果に応じて、対応するHTTPリクエスト（レスポンスライン、レスポンスヘッダー、レスポンスボディ）を生成します。

Nginxもこのルーチンです。全体的なプロセスは同じです。

モジュール式アーキテクチャ

Nginxモジュールは、基本的に機能に応じて次のタイプに分類できます。

①イベントモジュール：オペレーティングシステムに依存しないイベント処理メカニズムのフレームワークを構築し、特定のイベントの処理を提供します。ngx_events_module、ngx_event_core_module、ngx_epoll_moduleなどを含みます。

Nginxが使用するイベント処理モジュールは、特定のオペレーティングシステムとコンパイルオプションによって異なります。

②フェーズハンドラー：このタイプのモジュールは直接ハンドラーモジュールとも呼ばれます。これは主に、クライアント要求の処理と応答するコンテンツの生成を担当します。ngx_http_static_moduleモジュールは、クライアントの静的ページ要求を処理し、対応するディスクファイルを応答コンテンツ出力として準備します。

③出力フィルター：フィルターモジュールとも呼ばれ、主に出力コンテンツの処理を担当し、出力を変更できます。

たとえば、すべての出力HTMLページに定義済みのフットバーを追加したり、出力画像のURLを置き換えたりするなどのタスクを実装できます。

④アップストリーム：アップストリームモジュールは、リバースプロキシの機能を実現し、実際のリクエストをバックエンドサーバーに転送し、バックエンドサーバーからの応答を読み取り、クライアントに送り返します。

アップストリームモジュールは特別なハンドラーですが、応答コンテンツは実際にはそれ自体では生成されず、バックエンドサーバーから読み取られます。

⑤load-balancer：特定のアルゴリズムを実装する負荷分散モジュール多くのバックエンドサーバーの中から、特定の要求の転送サーバーとしてサーバーを選択します。

一般的な問題の分析

Nginx 対 Apache

Nginx：

IO多重化、Epoll（freebsdのkqueue）
ハイパフォーマンス
高い並行性
占有するシステムリソースが少ない

Apache：

ブロッキング+マルチプロセス/マルチスレッド
安定性が高く、バグが少ない
その他のモジュール

シーン：

複数のリクエストを処理する場合、以下を使用できます：IO 多路复用 または 阻塞 IO +多线程

1. IOの多重化：一个 线程複数のソケットのステータスの就绪読み取りと書き込みのどちらかを追跡します。

2.ブロッキングIO + マルチスレッド：リクエストごとに、新しいサービススレッドを作成します。

思考：IO 多路复用 と 多线程 該当シーン？

IO 多路复用：単一接続の要求処理速度には利点がなく、IO集約型の シナリオ、イベント駆動型に適しています

大規模な同時実行性：多数の同時要求を処理するために1つのスレッドのみが使用されるため、コンテキスト切り替えの損失が減少し、同時実行性の問題を考慮する必要がなく、比較的多くの要求を処理できます。
消費するシステムリソースが少ない（不要线程调度开销）
长连接状況に適用可能（マルチスレッドモードは発生し长连接やすい线程过多、原因です频繁调度）

阻塞IO + 多线程：シンプルな実装、システムコールに依存する必要がなく、CPU集中型の シナリオに適しています

各スレッドには時間とスペースが必要です。
スレッド数が増えると、スレッドスケジューリングのオーバーヘッドが指数関数的に増加します。

Nginxの最大接続数

基本的な背景：

Nginxはマルチプロセスモデルであり、ワーカープロセスはリクエストの処理に使用されます。
単一のプロセス（ファイル記述子fd）の接続数には上限（nofile）があります：ulimit -n。
Nginx上の単一のワーカープロセスの最大接続数を構成します。worker_connectionsの上限はnofileです。
Nginxのワーカープロセスの数を構成します：worker_processes。

したがって、Nginxの最大接続数：

Nginxの最大接続数：ワーカープロセスの数x単一のワーカープロセスの最大接続数。
上記は、Nginxを一般的なサーバーとして使用した場合の最大接続数です。
Nginxがリバースプロキシサーバーとして使用されている場合、サービスを提供できる最大接続数：（ワーカープロセスの数x単一のワーカープロセスの最大接続数）/ 2。
Nginxリバースプロキシの場合、クライアントの接続とバックエンドWebサーバーの接続が確立され、2つの接続が使用されます。

Nginxの同時処理機能

Nginxの同時処理能力：同時接続数。一般的な最適化の後、ピーク値は約1〜3wに維持できます。（メモリとCPUコアの数は異なります。さらに最適化する余地があります）。