Pleskウェブサーバ

Keep Alive Webサーバー：パフォーマンスを低下させる要因を正しく設定する

Keep Alive Webサーバーは、待ち時間や速度を決定する要素となることがよくあります。設定を誤ると、動作が鈍くなり、適切に調整すると、すべてのリクエストが顕著に高速化されます。具体的に、私がどのように キープアライブ どの時間帯が効果的か、また、長時間開いているとどのような影響があるかを設定する。 TCP-接続のパフォーマンスにコストがかかる。.

中心点

メカニズム: オープンTCP接続はハンドシェイクを節約し、遅延を削減します。.
中核的価値観: KeepAliveTimeout、MaxKeepAliveRequests、および有効化を意図的に選択してください。.
サーバー負荷: 適切に調整されたタイムスロットは、CPU および RAM の要件を削減します。.
練習: ブラウザの動作とリバースプロキシチェーンを常に考慮に入れる。.
コントロール測定、調整、再測定 – スイートスポットが見つかるまで繰り返します。.

Keep Alive の機能

各リクエストを新しいハンドシェイクで開始する代わりに、Keep-Alive は TCP-接続を開いたまま、それを通じて複数のリクエストを処理します。3 つのクライアントから 1 秒間に 50 件のリクエストがあるシナリオでは、パケットの流量が大幅に減少します。推定 9,000 パケットから 1 分あたり約 540 パケットに減少します。これは、接続数が減少し、ハンドシェイクの実行数が減少するためです。これにより、待ち時間が短縮され、サーバーサイクルが節約され、直接的な効果があります。 ローディング時間 およびスループットがあります。テストでは、残りのチェーンに制限がない場合、時間が約 1,190 ミリ秒から約 588 ミリ秒、つまり 50% 以上短縮されます。そのため、私は常に設定の早い段階でキープアライブを固定し、ライブトラフィックで実際の遅延を制御しています。.

適切な指標

まず、常に効果のある3つの調整項目から始めます。アクティベーション、接続あたりのリクエスト数、および閉じるまでの時間枠です。接続. アクティベーションは再利用が行われるかどうかを決定し、最大リクエスト数は接続を有効に維持する時間を制御し、タイムアウトは経済性と応答性のバランスを調整します。時間枠が大きすぎると、スロットがブロックされ、RAM が無駄になります。これは、非アクティブなソケットが残ったままになり、ワーカーが不足するためです。時間枠が短すぎると、サーバーが早期に切断して再起動する必要が生じるため、メリットが失われます。私は、最小限のデフォルト設定を堅持し、アイドル状態での実際の待ち時間が測定によって確認された場合にのみ、設定値を大きくしています。.

HTTP/1.1 対 HTTP/2/3：分類

Keep-Alive は TCP 接続ごとに機能します。HTTP/1.1 では、複数のリクエストが 1 つの回線を順番に共有しますが、HTTP/2 では、複数のリクエストが 1 つの回線を共有します。 ストリーム 単一の接続で多重化され、HTTP/3 は TCP の代わりに QUIC を使用します。私はこれを次のように分類します。HTTP/2 でも、短いタイムアウトは有意義です。アイドルストリームは無料ではないため、接続は引き続きリソースを消費します。特に ティーエルエス. Nginx は HTTP/2 について独自のアイドルウィンドウを持っています。グローバルなキープアライブ値と HTTP/2 特定の限界値が互いに適合し、無制限に高くならないように注意しています。重要：Nginx は現在、クライアントに対してのみ HTTP/2 を話します。バックエンドに対しては、 HTTP/1.1-接続は開いたまま。そのため、エンドツーエンドの利点を維持するには、アップストリームキープアライブが必須となります。HTTP/3 でも同様の原則が適用されます。QUIC は損失をよりよく隠蔽しますが、長時間開いたままの未使用のチャネルは、メモリとファイルディスクリプタを消費します。そのため、私のアプローチは保守的なままです。短いアイドルウィンドウ、明確な制限、そして無限の保持よりもクリーンな再接続を優先します。.

TLSのオーバーヘッドを実用的に考察

TLS は、ハンドシェイクが純粋な TCP 構築よりもコストがかかるため、Keep-Alive によって節約効果をさらに高めます。TLS 1.3 とセッション再開により負荷は軽減されますが、結局のところ、再接続を回避できることが最大のメリットとなります。私は実際に 3 つの点を確認しています。まず、サーバーがセッション再開を適切に使用しているかどうか（チケットを早期に失効させない）。次に、古いクライアントに不必要な負担をかけずに、強力な暗号と最新のプロトコルが有効になっているかどうか。第三に、高い並列性でも CPU 使用率が安定しているかどうか。再開機能があっても、短くて安定したキープアライブのタイムウィンドウは、ネゴシエーションの開始回数が減るため、CPU の追加的なピークを回避します。同時に、ウィンドウを長くしすぎてもハンドシェイクを妨げることはなく、負荷を非アクティブ状態に移すだけなので、よりコストのかかる方法となります。.

Apache：推奨設定

Apache では、KeepAlive をオンにします。オン, 、MaxKeepAliveRequests を 300～500 に設定し、時間枠は通常 2～3 秒を選択してください。最大リクエスト数の値を 0 に設定するのは魅力的に思えますが、無制限に設定することは、接続が長くなりすぎるため、ほとんどの場合、意味がありません。 接着する. 安定したクライアントによる高頻度のアプリケーションでは、5～10 秒をテストします。短時間の訪問が集中するピーク時には、1～2 秒に短縮します。重要なのは、まずタイムアウトを調整し、次にリクエストの数をより細かく設定して、スロットがアイドル状態でブロックされないようにすることです。メイン設定にアクセスできない場合は、ホスティング事業者がこのオプションを有効にしている限り、mod_headers を使用してディレクトリごとの接続動作を制御することができます。.

Nginx：効果的なチューニング

Nginx では、Keep-Alive はデフォルトで有効になっているため、私は主にタイムアウト、ブラウザの例外、および接続あたりの数に注目しています。keepalive_timeout を使用して、トラフィックパターンに応じて 1 秒から 5 秒まで段階的に調整するオープン秒数を設定します。API 呼び出しが多い場合は、10 秒も有効である場合があります。 keepalive_disable を使用して、問題のある古いクライアントを排除し、不正な セッション 生成します。アップストリームへのリバースプロキシでは、Nginx がバックエンドへの接続を再利用し、そこでより少ないワーカーをバインドするように、追加で upstream keepalive を設定します。これにより、エンドツーエンドのパスを一貫性のある状態に保ち、望ましくない別れリクエストフローの真っ只中。.

リバースプロキシとヘッダー転送

多段階のセットアップでは、一貫した戦略, HTTP/1.1 ヘッダーを正しく転送し、接続値を誤って上書きしないもの。Nginx はバックエンドに対して HTTP/1.1 を話し、Keep-Alive を明示的に許容し、Apache はその背後で適切な時間枠を利用すべきです。 Connection: close を強制したり、アップグレードパスを妨害したりする設定は、想定されるメリットが失われるため、重大な問題となります。Apache では、mod_headers を使用して、接続を開いたままにするかどうか、および追加情報を設定するかどうかを場所ごとに制御できます。すべてのノードは同じ目標を追求する必要があります。そうしないと、1 つのリンクが 制動効果, 、私は本来は避けたいと思っていた。.

CDN、ロードバランサー、クラウド設定

CDN またはロードバランサーが前にある場合、ほとんどのクライアント接続はそこに到達します。その結果、エッジとオリジン間の接続数が少なく、持続的な接続が維持されるというメリットがオリジンにもたらされます。私は、バランサーも短いアイドルウィンドウで動作し、バックエンドへの接続プールが有効になっていることを確認しています。コンテナおよびクラウド環境では、ドレインフローも重要です。ローリングアップデートを行う前に、ノードを ドレナージ-ステータス、未処理の接続を迅速に終了させ（タイムアウトは長すぎないように）、その後で代替を開始します。これにより、切断されたリクエストや残されたゾンビ接続を回避できます。スティッキーセッション（クッキーなど）は接続プールを分割する可能性があります。可能な場合は、ステートレスな バックエンド または外部セッションストアを使用して、再利用が均等に機能するようにします。.

実際のホスティング速度

多くの共有環境では、短期的な スロット 節約できますが、ページは重くなり、インタラクティブ性が失われます。そのため、私は早い段階でロード時間テストを行い、サーバーが再利用を許可しているかどうか、またウォーターフォールチャートで接続フェーズがどのように表示されるかを確認しています。このツールが、多くの小さなアセット間で長いハンドシェイクブロックを検出する場合、ほとんどの場合、再利用が行われていないか、タイムアウトが早すぎることを意味します。さらなる微調整には、このコンパクトなガイドのような構造化されたガイドラインが役立ちます。キープアライブチューニング, そうすることで、手順をきちんとこなせるんだ。そうすれば、当て推量を避け、ほんの数ステップで目に見える成果を上げられるんだ。勢いフロントエンドで。

タイムアウト、制限、ブラウザの動作

最新のブラウザは、ホストごとに複数の並列 コネクション, 、多くの場合 6 回、それによりキープアライブの容量をすぐに使い切ってしまう。MaxKeepAliveRequests を 300 に設定すると、タイムアウトが不必要に高く設定されていない限り、実際には多くの同時訪問者に十分対応できる。ウィンドウを 3 秒に設定すると、スロットが利用可能であり続け、サーバーはアイドル状態よりもアクティブなクライアントを優先します。リクエストが定期的に途絶えるか、再利用が機能しない場合にのみ、制限を適度に段階的に引き上げます。多くの HTTP/2 ストリームがあるページについては、別途検討が必要であり、詳細は HTTP/2 マルチプレキシング非常にコンパクトにまとめて、チャネルの使用とキープアライブを明確に整理できるようにしています。.

パラメータ	Apache ディレクティブ	Nginx ディレクティブ	基準値	ヒント
活性化	KeepAlive オン	デフォルトで有効	常に有効にする	再利用なしでは増加するオーバーヘッド.
タイムアウト	KeepAliveTimeout	keepalive_timeout	2～5秒	多くの短い呼び出しではより短く、より長い呼び出しではより長く API.
数/コネクション	MaxKeepAliveRequests	keepalive_requests	300～500	リソースの拘束を制限するクライアント.
ブラウザの例外	-	keepalive_disable	選択的	非常に古いものを無効にするクライアント.
上流	ProxyKeepAlive	アップストリームキープアライブ	アクティブ	再利用の方向性を確保バックエンド.

オペレーティングシステムの制限とソケット

OS レベルでは、ファイルディスクリプタとソケットパラメータが実際の容量を制限します。ulimit -n、プロセスおよびシステム制限、Web サーバーの設定（Nginx の worker_connections など）を確認します。Keep-Alive は新しい接続の数を減らしますが、ディスクリプタが占有される時間を長くします。トラフィックが集中する時間帯には、接続が急速に閉じることで TIME_WAIT の負荷が発生する場合があります。この場合は、積極的なカーネルハックよりも、クリーンな再利用が特に有効です。私は HTTP とキープアライブ （アプリケーションプロトコル）とカーネルの TCP キープアライブプローブ：後者は純粋な生存確認パケットであり、オープン HTTP ウィンドウと混同しないでください。私は測定ポイントのみを使用してカーネルのデフォルトを変更し、主に Web サーバー自体に設定します。短いが効果的なアイドルタイムアウト、接続ごとのリクエスト制限、そして妥当なワーカーリザーブです。.

安全性：スローロリス＆カンパニーの危険性を軽減

寛大なキープアライブ値は悪用を招きます。そのため、アイドル時間だけでなく、読み取りおよびボディのタイムアウトも制限しています。Nginx では client_header_timeout および client_body_timeout を使用しています。Apache では、適切なモジュールを使用して厳しい読み取り制限を設定し、遅いリクエストがワーカーをブロックしないようにしています。ヘッダーサイズとリクエストボディの制限は、メモリの肥大化も防止します。適度なキープアライブウィンドウと組み合わせることで、少数のクライアントが多くのソケットを占有するリスクを低減します。重要なのは順序です。まず正しいタイムアウト、次に的を絞った制限、最後にレートまたは IP 関連のルールを設定します。そうすることで、実際のユーザーは高速な状態を維持でき、攻撃プロファイルは空振りになります。.

モニタリングと負荷テスト

変更のたびに、ab、wrk、k6 などのツールを使用してその効果を測定し、95パーセンタイルを確認しています。 遅延時間. まず、タイムアウトを明確な段階的に減らして、タイムアウトや接続切断が増えるかどうかを確認します。それから、接続ごとのリクエスト数を調整します。同時に、オープンソケット、ワーカーの負荷、メモリ要件を評価して、適切な場所でアイドル状態をカットします。繰り返し発生する待ち時間については、バックエンドのキューを確認する価値があります。キーワードはサーバーキューイングおよびリクエストの分散。測定ポイントを使用すると、ボトルネックを早期に認識でき、長い時間を節約できます。 トラブルシューティング.

ログとメトリクスの実践

接続が実際に再利用されているかどうかを確認したい。Nginx では、接続カウンターと時間をログ形式に追加しています。この値により、クライアントが 1 つの接続で多くのリクエストを送信しているかどうか、あるいは 1、2 回のヒット後に接続を閉じているかどうかがわかります。Apache でも同様に、接続ごとのリクエスト数を表示しています。これにより、タイムアウトやリクエスト制限の恩恵をより多く受けているパターンを特定することができます。.

# Nginx: 拡張ログ形式の例 log_format main_ext '$remote_addr $request ' 'conn=$connection reqs=$connection_requests ' 'rt=$request_time uct=$upstream_connect_time';

access_log /var/log/nginx/access.log main_ext;

# Apache: 接続と継続時間を含む LogFormat LogFormat "%h %r conn:%{c}L reqs:%{REQUESTS_PER_CONN}n time:%D" keepalive CustomLog logs/access_log keepalive

モニタリングでは、中央値に加えて、P95/P99 レイテンシ、アクティブな接続、リクエスト/接続の分布、エラーエッジ（増加する 408/499）に特に興味があります。これらが小さなキープアライブウィンドウで上昇した場合、私は適度に後退します。負荷が平らでレイテンシが改善されたままなら、スイートスポットに到達したことになります。.

デプロイとローリング再起動

リロードとアップグレードは、きちんと計画すればキープアライブと両立するよ。Nginx では、スムーズなリロードを重視して、ワーカー接続をハードにカットするんじゃなくて、制御しながら処理してるんだ。短いアイドルタイムアウトは、古いワーカーを早く解放するのに役立つよ。Apache では、 しとやか-再起動し、mod_status またはステータスページを同時に監視して、待機中のリクエストが失われないようにします。大規模なデプロイの前に、システムをより早く空にするためにキープアライブウィンドウを一時的に下げ、安定性チェック後に目標値に戻します。重要：変更を文書化し、負荷プロファイルと比較して、気づかないうちに速度が低下しないようにしてください。回帰忍び込む。.

よくある間違いと対策

長すぎる時間枠は非アクティブ状態を維持する コネクション この問題は、ワーカーのボトルネックに発生し、新規訪問者のアクセスを著しく遅らせます。接続あたりのリクエスト数に制限がないことは優れているように見えますが、結局、ソケットあたりの負荷が増大し、負荷のピークが制御不能になります。1 秒未満の非常に短いウィンドウでは、ブラウザが継続的に再構築され、ハンドシェイクの割合が増加し、フロントエンドがぎくしゃくした動きになります。プロキシチェーンでは、一貫性が欠けていることがよくあります。あるリンクが HTTP/1.0 を使用したり、Connection: close を設定したりして、再利用を妨げているのです。そのため、私は次の順序で作業を進めています。有効化を確認し、タイムアウトを少しずつ調整し、接続ごとのリクエストを調整し、測定値が実際に ベネフィット ショー

迅速な実施のためのチェックリスト

まず、キープアライブを有効にして、現在の 価値観, いつでも元に戻せるようにね。それから、タイムアウトを3秒に設定して、設定を再読み込みして、フロントエンドのオープン接続、使用率、ウォーターフォールをチェックするんだ。短い訪問が多い場合は、2秒に下げて、APIロングポーリングが多い場合は、5～10秒に少し上げるよ。その後、MaxKeepAliveRequests を 300～500 に設定し、スロットが空き続けるか、あるいは強力な常時接続クライアントが長すぎる時間接続し続けるかを観察します。各ステップの後、再度測定を行い、その影響を記録し、最適な設定を保持します。 コンビネーション 固定。.

ショートバランスシート

正しく設定されたキープアライブは、ハンドシェイクを節約し、レイテンシを削減し、サーバーにさらなるメリットをもたらします。空気リクエストごとに。短すぎず長すぎない時間枠と、接続ごとの適度なリクエスト数で、ホストは明らかにスムーズに動作するよ。最大値を盲目的に調整するよりも、明確な測定ポイントで小さな変更を加えることを重視しているんだ。ホスティング、リバースプロキシ、バックエンドを一貫して再利用に重点を置くことで、不必要なリソースの拘束なしに、迅速な相互作用を実現できます。最終的には測定結果が重要です。真の数値だけが、チューニングが期待どおりの効果をもたらしたかどうかを示します。効果を持ってくる。