目次
1. プロセスチューニング
worker_processes、ワーカー プロセスの数
1.デフォルト: ワーカープロセス: 1
2. 増加:worker_processes: CPU コアの数 (デュアル コア 4 スレッド、4 に設定可能)
work_connections は、単一のワーカー プロセスが同時に確立できる外部接続の数であり、2 つの指標に大きく関連しています。1 つはメモリ、もう 1 つは「プロセスが開くことができるファイルの最大数」です。オペレーティング システム レベル。
数値が大きいほど、より多くの接続を同時に処理できます。
1.デフォルト: ワーカー接続数: 1024
2.调大：worker_connections: 65535
worker_rlimit_nofile #Nginx ワーカー プロセスでオープンできるファイルの最大数を構成します
include mime.types; #Type import/usr/local/nginx/conf/mime.types ファイル。
default_type text/html; #デフォルト タイプのブラウザがこの種類のファイルを取得すると、自動的に HTML パーサーを呼び出して、それに応じてファイルを処理します。
log_format #/usr/local/nginx/logs ログ ストレージ パスを開くためのログ形式を定義します
server_tokens off; #バージョン番号を隠す
sendfile on; #効率的なファイル転送モードは、クライアントを経由せずにカーネルから直接送信されます。
#tcp_nopush on; #sendfile モードでは、TCP_CORK オプションを有効にするかどうかに関係なく、1 つのファイルに 1 つのメッセージが送信され、アプリケーション層ヘッダーは 1 つのファイルを個別に必要とするのではなく、1 回だけ必要とします。
keepalive_timeout #各 TCP 接続を維持できる最長時間を指定します。
gzip on; gzip 圧縮をオンにします。通常、ユーザーに返されるテキスト要求コンテンツは、帯域幅を節約するために圧縮されます。
client_max_body_size #ユーザーが最大データ サイズをアップロードできるように nginx サービスを設定します
client_header_buffer_size 8k; # リクエストライン+リクエストヘッダの標準サイズは8kです
large_client_header_buffers 4 8k; # リクエストライン + リクエストヘッダーの最大サイズは 32k
負荷分散は、「アップストリーム」モジュールによって定義されたバックエンド サーバー リストからユーザー リクエストを受け入れるサーバーを選択するために使用されます。
1. ポーリング
最も基本的な構成方法であり、アップストリーム モジュールのデフォルトのロード バランシング戦略です。各リクエストは時系列順に 1 つずつ異なるバックエンド サーバーに分散されます。
次のパラメータがあります。
failed_timeout は max_fails と組み合わせて使用されます。max_fails は、fail_timeout パラメータで設定された時間内の失敗の最大数を設定します。この時間内にサーバーへのすべてのリクエストが失敗した場合、サーバーはダウンしているとみなされます。fail_time サーバーは、一定時間ダウンしているとみなされます。デフォルトは 10 秒です。バックアップは、サーバーをバックアップ サーバーとしてマークします。メインサーバーが停止すると、リクエストがメインサーバーに送信されます。down はサーバーが永続的にダウンしていることをマークします。
知らせ：
- ポーリング中にサーバーがダウンすると、サーバーは自動的に削除されます。
- デフォルト設定はポーリング戦略です。
- この戦略は、サーバー構成が比較的安定しており、ステートレスで短く高速なサービスに適しています。
2、重量
重み付け方法では、ポーリング戦略に基づいてポーリングの確率を指定します。重みパラメータはポーリング確率を指定するために使用されます。重みのデフォルト値は 1 です。重みの値はアクセス率に比例します。たとえば、サーバーの 1 つが重み = 2 である場合、サービスがアクセスされる確率は他のサーバーの 2 倍になります。
知らせ：
- 重みが大きいほど、処理する必要があるリクエストが多くなります。
- この戦略は、least_conn および ip_hash と組み合わせて使用できます。
- この戦略は、サーバーのハードウェア構成が大きく異なる状況に適しています。
3、ip_ハッシュ
クライアント IP に基づいて分散するロード バランサーを指定します。この方法により、同じクライアントからのリクエストが常に同じサーバーに送信され、セッションが確保されます。このようにして、各訪問者はバックエンド サーバーに固定的にアクセスできるようになり、セッションがサーバーを越えることができないという問題を解決できます。
知らせ：
- nginx バージョン 1.3.1 より前では、ip_hash で重みを使用できませんでした。
- ip_hash はバックアップと併用できません。
- この戦略は、セッションなどのステートフル サービスに適しています。
- サーバーを削除する必要がある場合は、手動でサーバーを停止する必要があります。
4、least_conn
接続数が少ないバックエンド サーバーにリクエストを転送します。ポーリング アルゴリズムは、負荷がほぼ同じになるようにリクエストを各バックエンドに均等に転送しますが、一部のリクエストには時間がかかるため、リクエストが配置されているバックエンドの負荷が高くなります。この場合、least_conn はより優れた負荷分散効果を実現できます。
知らせ：
- この負荷分散戦略は、リクエストの処理時間の変化によりサーバーの過負荷が発生する状況に適しています。
/data/app/nginx/conf/sites/extra/www.conf
listen 443 ssl #ポート 443 をリッスン
SSL プロトコル。Webブラウザとサーバー間の認証と暗号化されたデータ送信に広く使用されています。
server_name test.whispark.com; サービスのドメイン名
第 1 レベルのドメイン名: Whisper.com
第 2 レベルのドメイン名: www.whispark.com
第 3 レベルのドメイン名: image2.whispark.com
ドメイン名は IP アドレスに対応し、IP アドレスは複数のドメイン名にバインドできます。
購入する必要があるのは第 1 レベルのドメイン名のみで、その後の第 2 レベルと第 3 レベルのドメイン名は自由に定義できます。
access_log /usr/local/nginx/logs/front/wpwww.access.log main; サービス ログの保存パス
1.場所の役割
location ディレクティブの機能は、ユーザーが要求した URI に従ってさまざまなアプリケーションを実行すること、つまり、ユーザーが要求した Web サイトの URL を照合することであり、照合が成功した場合、関連する操作が実行されます。
- 場所の構文
| ディレクティブ | | ID の一致 | | 一致した Web サイトの URL | | URI の一致後に実行される構成セグメント |
場所 [ = | ～ | ~* | ^~ ] ウリ { .... }
一致ID
=: URI と完全に一致
~ : URI の正規表現パターン マッチング、大文字と小文字は区別されます。
~* : URI の正規表現パターン マッチング。大文字と小文字は区別されません。
^~ : URI の左半分が一致するかどうかを確認します。文字は大文字と小文字が区別されません。
記号なし: この URI から始まるすべての URL と一致します。
一致する優先順位: =、^~、 ~/~*、符号なし。
/data/app/nginx/conf/sites/extra/www.conf
proxy_pass プロキシ転送では、proxy_pass の後の URL に / を付けると絶対ルートパスを意味し、/ が無い場合は相対パスを意味し、一致するパス部分もプロキシに与えられます。
proxy_cookie_path は Cookie のパスを変更するために使用されます。
proxy_redirect off リダイレクトをオフにする
プロキシセットヘッダー
1、X-リアルIP
これはクライアントの実 IP を指します。$remote_addr の値が設定されている場合、バックエンド サーバーはクライアントの実 IP を取得できます。
2、ホスト
クライアントから送信されるリクエスト ヘッダーには HOST フィールドがありません。$host は nginx プロキシ サーバーのアドレスを表します。
3、X-Forwarded-For
この変数の値には $proxy_add_x_forwarded_for と $remote_addr が含まれます。転送するプロキシ サーバーが 1 つだけの場合、2 つの効果は似ているように見え、両方ともクライアントの元の IP を実際に表示できます。
- $http_upgrade をアップグレードします。接続「アップグレード」;
Http アップグレード メカニズムを通じて Http を WebSocket にアップグレードします。Nginx プロキシ サーバーは、WebSocket がホップバイホップ プロトコルに属するという問題を構成を変更することで解決し、クライアントとサーバーとの接続を開いたままにすることで WebSocket プロキシを実装します。
nginx には、ルートとエイリアスという 2 つのファイル パスを指定する方法があります。ディレクティブの使用法と範囲は次のとおりです。
ルートとエイリアスの主な違いは、nginx が場所の後の URI を解釈する方法であり、これにより、ルートとエイリアスは異なる方法でリクエストをサーバー ファイルにマップします。
ルートの処理結果は、ルートパス+ロケーションパスとなります。
エイリアス処理の結果は次のようになります。ロケーション パスをエイリアス パスに置き換えます。
alias はディレクトリ エイリアスの定義であり、root は最上位ディレクトリの定義です。
もう 1 つの重要な違いは、エイリアスが「/」で終わる必要があることです。そうしないとファイルが見つかりません。
エラーページ
アクセス要求時にこれらのステータスコードが表示された場合、50x-pc.htm の内容が返されるため、ユーザーのアクセスにより 502 と 503 が発生した場合、ユーザーに返されるステータスは 200、内容は 50x.html となります。