Pleskウェブサーバ

パフォーマンスを最大化するためにApacheのKeepAliveタイムアウトを最適に設定する

私はそれを アパッシュ keepaliveタイムアウトを、貴重なワーカーをブロックすることなく、接続を効率的に再利用できるよう設定します。明確な基準値と測定ポイントを基に、私は タイムアウト スループットの向上とページ表示速度の高速化を目的として設計されています。.

中心点

キープアライブ TCP／TLSのオーバーヘッドを削減し、遅延を低減します。.
タイムアウト Apacheが新しいリクエストを待機する時間を制御します。.
短すぎる 握手には費用がかかります、, 長すぎる ワーカーをバインドします。.
標準値: 2～5秒（API/負荷）、3～5秒（Web）、5～15秒（アセット）。.
イベント-MPM そして、モニタリングによって、実際の効果が確実に得られる。.

Apacheにおける「Keep-Alive」と「KeepAliveTimeout」の役割

HTTPのKeep-Aliveは、クライアントからの複数のリクエストを1つのTCP接続にまとめ、それによって CPU およびTLSハンドシェイク。このディレクティブは キープアライブ この設定は当該動作を有効にし、KeepAliveTimeout は Apache が非アクティブな接続を切断するまでの待機時間を秒単位で指定します。一般的な初期設定値は、KeepAliveをOn、KeepAliveTimeoutを5、MaxKeepAliveRequestsを100～500に設定することで、適切なバランスが保たれます。タイムアウトが長すぎると、それ以上のリクエストが来ていないにもかかわらず、プロセスがアイドル状態のままになります。逆に短すぎると、新しい接続を強制することになり、レイテンシが高くなります。そのため、私は、関連するリクエストをカバーしつつ、ワーカーを長時間拘束しないような、ぎりぎりの時間枠を設定しています。.

短すぎるか、長すぎるか：決定的な目標の対立

短いタイムアウトは、ページビューあたりの新規接続数を増加させ、その結果、 オーバーヘッド. 画像、CSS、JS といった多くの小さなアセットは、再利用された接続、つまりあまりに乏しくない タイムアウト. 一方、タイムアウト時間が長すぎると、貴重なワーカーが占有され、負荷がピークに達した際にキューが発生する可能性があります。その結果、実際の処理は迅速に行えるにもかかわらず、応答が遅くなったりエラーメッセージが表示されたりすることになります。経験上、高密度で高速なワークロードでは2～5秒が最適ですが、5～15秒はリソースが十分に確保されている場合にのみ有効です。60秒を超える設定は、生産環境ではあまり意味がありません。なぜなら、あまりにも多くのプロセスがアイドル状態に陥ってしまうからです。.

ワークロードに応じた推奨基準値

私は明確なプロファイルに基づいて判断しています。APIサーバーには通常2～3秒が割り当てられます。これは、高速なスループットと迅速な承認が求められるためです。 労働者 が必要です。アセットの多い従来のウェブサイトでは、ウォーターフォールリクエストを適切に束ねるために3～5秒程度あれば十分です。非常に多くの小さなファイルを含むアセットドメインの場合、十分なリソースがあれば5～10秒程度まで許容されます。Apacheの前にリバースプロキシが存在する場合は、プロキシがクライアント接続を処理するため、その背後で1～2秒という短いタイムアウトを設定します。管理. 基礎をより深く学びたい方には、以下の資料が確かな入門書となります。設定ガイド.

実務に即した初期設定

Event-MPM を採用した最新のウェブサイトでは、KeepAliveTimeout の初期値を 3 秒、MaxKeepAliveRequests を 300 に設定すると、非常に 効率的. 。こうすることで、ページ閲覧に伴う関連するリクエストの大部分をカバーしつつ、アイドル状態になるリスクを回避できます。APIサーバーは、多くの場合、2秒のタイムアウトと200～300のMaxKeepAliveRequestsで起動しており、これにより待ち時間を短縮し、 スループット 増加します。CPUやRAMに余裕のあるリソース集約型のホストでは、タイムアウトを5～10秒、MaxKeepAliveRequestsを500～1000に設定すると、多くの場合、その恩恵を受けられます。静的な最小ページでは、キープアライブによってメリットが得られることはめったにありません。そのため、テストで明らかな利点が確認できた場合に限り、時折これを無効にしています。.

MPMおよび関連するディレクティブを適切に組み合わせる

イベントMPMは、非アクティブな接続を特に厳格に処理するため、KeepAliveTimeoutを適度に短く設定しても 危険な となります。さらに、グローバルなタイムアウト設定も確認します。これはKeepAliveTimeoutよりも明らかに高い値、多くの場合30～60秒に設定されているべきです。MaxKeepAliveRequestsは、パターンに応じて200～500の間で設定し、純粋なアセットホストの場合は、条件が許せばさらに高い値に設定します。 攻撃のリスク 常に注意を払う。そうすることで、クライアントが多数の小さなファイルを取得する場合でも、Apacheのパフォーマンスを維持できます。設定ミスは重大な問題となり、不要なハンドシェイクを発生させたり、ワーカーを長時間占有させたりする原因となります。最適な設定は、テスト、観察、そして段階的な調整を繰り返すことで導き出されます。.

モニタリングを活用した段階的な最適化

まずはトラフィック分析から始めます。アセットの数、一般的な読み込み時間、バースト動作、リクエスト間の間隔などは、 タイムアウト 決定的です。その後、初期値を設定します：混合ワークロードの場合は3秒、APIの場合は2秒、アセットドメインの場合は5秒です。続いて、開いている接続、RAM、CPU、応答時間、エラーコードを監視します。非アクティブな接続によって多くのワーカーが占有されている場合は、 待ち時間. 一方、新しい接続が増え、レイテンシが上昇する場合は、1～2秒ずつ少しずつ増やしていきます。体系的な手順については、以下の短いパフォーマンス調整ガイド.

指標を読み取り、正しく解釈する

server-status、アクセスログ、ウォーターフォール図を確認すると、リクエストが時間的にどのように重なっているか、また接続がどのくらいの時間続いているかがわかります。 スタンド. 新しいTCP／TLS接続の確立率が高い場合は、KeepAliveTimeoutが短すぎることを示しています。非アクティブな接続を持つアイドル状態のワーカーが多い場合は、待ち時間が長すぎることを示唆しています。これらの調査結果をユーザー体験と照らし合わせています。ページの読み込みは明らかに速くなったか、それとも中断が増えているか？ 503/504エラーの増加に対しては、アイドル時間を短縮するか、あるいは 労働者. 。こうして、一歩一歩「スイートスポット」に近づいていく。.

ワークロードプロファイル：ウェブサイト、API、プロキシ

アセットの多いウェブサイトでは、短い間隔で複数のリクエストをまとめて接続, 、そのため3～5秒が適しています。APIの場合は、リソースの迅速な解放が重要となるため、2～3秒程度に抑えるのが効果的です。上流にリバースプロキシを配置する場合、Apacheのバックエンド処理時間を短く設定します（多くの場合1～2秒）。これは、プロキシが クライアント-永続性が影響します。ファイル数が少ない静的ページでは、キープアライブによるメリットはほとんどありません。私はオン／オフを切り替えてテストし、客観的に測定しています。最適な値を決めるのはプロファイルであり、希望的観測ではありません。まさにその理由から、トラフィックに変化がないかを定期的に確認しています。.

表：タイムアウトに関する推奨事項と影響

以下の概要では、代表的な利用シナリオを具体的な数値と関連付け、その主な効果やリスクを挙げています。私はこれを 出発点 その後、実際の測定値と照らし合わせて、最終的な値を微調整します。注意：この範囲は参考となる目安であり、厳格な基準ではありません。システムの反応を明確に把握できるよう、変更は少しずつ行うべきです。そうして初めて、その効果を実証可能に保つことができ、 わかりやすい.

シナリオ	KeepAliveTimeout	MaxKeepAliveRequests	主な効果	潜在的なリスク
API／マイクロサービス	2～3秒	100-300	迅速な承認、処理能力の向上	値が小さすぎる場合の新規接続が増加
豊富なアセットを掲載したウェブサイト	3～5秒	300～500	ハンドシェイクの回数が減り、読み込み時間が短縮される	過負荷の場合は、必要に応じてワーカーをアイドル状態にする
アセットドメイン（ファイル数が非常に多い）	5-10 s	500–1000	多数のリクエストをうまくまとめる	化合物の結合持続時間の延長
Apache の前のリバースプロキシ	1～2秒	100-300	高速なバックエンド、プロキシがクライアント接続を維持する	まれなバーストシーケンスでは長さが不足している
静的ミニマルページ	オフ、または1～2秒	ロー	ワーカーごとの最大スループット	再利用によるメリットがない

私はこれらの指標を最初のロードマップとして設定し、未解決の案件などのメトリクスを使って確認しています。 コネクション, 、レイテンシ、エラー率。数値からボトルネックが判明した場合は、タイムアウトとMaxKeepAliveRequestsを段階的に調整します。測定を行わずに調整を行うと、往々にして逆効果になります。明確な観察を行いながら少しずつ変更を加える方が賢明です。そうすることで、パフォーマンスの再現性が保たれ、 和気あいあい.

設定のテスト：ツールと手順

私は、すべての変更について、合成負荷テストと実際のトラフィックを用いて検証を行い、これにより 測定値 負荷に耐えられるかどうかを確認します。ab、wrk、k6 などのツールを使って、負荷がかかった状態でのスループットやエラーの分布を把握します。並行して、server-status やログを確認し、アイドル時間、新規接続、応答時間を確認します。変更のたびに、数値に有意な変化が見られるまで十分な時間をおきます。実際の作業順序については、コンパクトな最適化フロー. この規律のおかげで、私は「効果」と「偶然」を混同することがない マスト.

HTTP/2 と HTTP/3：キープアライブに関する変更点

HTTP/2 では、クライアントは単一の接続を介して多数の同時ストリームを束ねます。これにより、並行する TCP 接続の数が大幅に減少しますが、適切に設定された KeepAliveTimeout の重要性は依然として変わりません。典型的なストリームのシーケンス（HTML、CSS、JS、フォント、画像）が、新たなハンドシェイクを必要とせずにスムーズに処理されるよう、接続を十分に長く維持します。同時に、HTTP/2はバーストフェーズを1つのセッション内により効率的にまとめられるため、過度に長いタイムアウトを設定する必要はありません。実際の運用では、HTTP/2 環境において、私が設定しているウェブ上の目安（3～5 秒）が特に有効であることが実証されています。一部のモジュールには、ストリームやセッションに対する独自の HTTP/2 専用制限値が設定されていますが、私はこれらが KeepAliveTimeout と矛盾しないように注意しています。 HTTP/3（QUIC）では、接続確立のオーバーヘッドはさらに軽減されますが、基本的な考え方は変わりません。つまり、リソースを過度に保留することなく、典型的なリクエストグループを反映する時間枠を選択するということです。.

HTTP Keep-Alive 対 TCP Keep-Alive：明確に区別する

私は、HTTP Keep-Alive（アプリケーションプロトコル、後続のリクエストでの再利用）とTCP Keep-Alive（切断された接続を検出するOSのメカニズム）を厳密に区別しています。 net.ipv4.tcp_keepalive_time などの設定は、Apache が新しい HTTP リクエストを待機する時間には影響しません。これに関しては、KeepAliveTimeout のみが関連します。 OSのKeepaliveは、孤立したソケット（ネットワーク切断時など）を検出するのに役立ちますが、HTTPの挙動を制御する手段ではありません。これらのレベルを混同すると、測定値から誤った結論を導き出してしまうことがよくあります。そのため、私は以下を分けて検証しています：再利用と遅延に関するHTTPメトリクス、およびソケットの状態と接続品質に関するOSメトリクスです。.

キャパシティ計画：ワーカー・バジェットとタイムアウトを一体として考える

私は常に、KeepAliveTimeoutを全体的な並行処理予算（MaxRequestWorkers/ServerLimit）の範囲内で設定するようにしています。簡単な考え方として、接続がアイドル状態で待機する時間が長ければ長いほど、スループットを生み出さない状態で占有されるリソースの割合が大きくなる、という点が参考になります。例：リクエスト数が400リクエスト/秒で、KeepAliveTimeoutが3秒の場合、極端なケースでは、多数の接続に分散して、1秒あたり最大約1200秒のアイドル時間が発生する可能性があります。 Event-MPMは、アイドル状態を分離することでこの問題を緩和しますが、それでも上限効果（キャップ効果）は存在します。そのため、私は負荷曲線を監視しています。負荷のピーク時にビジーワーカー数が過度に増加する場合は、アイドルウィンドウを短縮するか、（RAMの状況を考慮しつつ）MaxRequestWorkersを慎重に増やします。目標は、バックエンドワーカーが主にアクティブな処理に従事し、アイドル時間がキューに転化しないようにすることです。.

スタック内のタイムアウトを一貫してバランスよく調整する

KeepAliveTimeoutに加え、私は常に関連する設定項目も確認しています。グローバルなタイムアウトディレクティブはI/O操作に対する厳格な上限を定義するものであり、Keep-Aliveの値よりもかなり高い値に設定すべきです。プロキシ環境では、Apacheが接続を早すぎるタイミングで切断したり、逆に長く保持しすぎたりしないよう、バックエンドごとにProxyTimeoutおよびtimeouts/connectiontimeoutオプションを個別に設定しています。 Slowlorisのような攻撃パターンに対しては、正当な低速クライアントに不必要な影響を与えないよう、防御的なRequestReadTimeout設定が有効です。 HTTP/2環境では、事実上Keep-Aliveウィンドウに上限を設けることになる、ストリームまたはセッションに関連する制限に注意を払っています。私の原則は、再利用のための短いアイドルウィンドウ、実際の処理作業のための余裕のある（ただし妥当な）上限、そして悪用に対する明確な防護策を設けることです。.

TLSのコストを現実的に評価する

最新の暗号技術を用いても、新しいTLSハンドシェイクは再利用よりも負荷が高くなります。セッション再開やTLS 1.3によってその負荷は著しく軽減されますが、完全に解消されるわけではありません。特にCPUに負荷がかかるワークロードや小規模なインスタンスでは、不要なハンドシェイク一つひとつが顕著に感じられます。そのため、短すぎず、かといって長すぎないKeepAliveTimeoutを設定することが特に効果的です：ページ呼び出しの密なシーケンスにおいてハンドシェイクを削減しつつ、接続を数分間もアイドル状態に保つことはありません。私が注目しているのは、最初のHTMLが配信された直後の数秒間です。その瞬間こそ、再利用による最大のメリットが得られるのです。なぜなら、その後のアセットのほとんどが短い間隔で次々と要求されるからです。.

モバイルネットワーク、「長い休止期間」、および不正利用からの保護

モバイルネットワークや広域ネットワークでは、RTTやパケット損失の変動がより大きくなります。タイムアウト設定が厳しすぎると、クライアントでわずかな遅延が発生しただけで、早期にタイムアウトとなってしまいます。そのため、私は実際のユーザープロファイルを評価しています。モバイルの割合が高い場合は、私のWebガイドラインの上限（4～5秒）を採用することが多く正当化されますが、純粋なデータセンター間APIであれば、2秒でも十分に機能します。同時に、悪用に対する対策も講じています。適度に制限的なRequestReadTimeout戦略と、IPごとの同時接続数制限を設けることで、少数のクライアントが多数のアイドル回線を占有してシステムのパフォーマンスを低下させることを防いでいます。リバースプロキシが前段に配置されている場合は、不安定なネットワークに対する堅牢性をリバースプロキシに任せ、バックエンドは厳格に管理しています。.

Apache、PHP-FPM、およびアップストリームの連携

PHPスタックでは、MaxRequestWorkers（Apache）とpm.max_children（PHP-FPM）の整合性を確認しています。 KeepAliveTimeoutが長すぎると、フロントエンドの接続がワーカーを「占有」したままになり、その間バックエンドではリクエストが空きPHPスロットを待機することになります。これが、レイテンシが突然急増する典型的な原因です。このリスクを最小限に抑えるため、アイドルウィンドウを短めに設定し、最も処理が遅い部分（多くの場合、PHP-FPMまたはデータベース）のボトルネックに合わせて規模を調整しています。リバースプロキシ（CDN、エッジプロキシ、または内部L7プロキシなど）の背後で動作する場合は、プロキシがクライアントに対して永続的なセッションを維持し、オリジンは実際の処理のためにのみ必要となるため、Apacheバックエンドのアイドルウィンドウを意図的に短くしています。.

厄介なケースのための分析プレイブック

影響が不明確な場合は、常に「外側から内側へ」という順序で調査を進めます。まずユーザーの視点（読み込み時間、ウォーターフォールチャート）、次にエッジ／プロキシ、続いてApache（server-status、Scoreboard）、最後にアプリケーションとデータベースという順です。新規接続の割合が著しく高い場合は、たいていKeepAliveTimeoutが短すぎるか、あるいは多数の短いリクエストを引き起こすコンテンツのパターンと相関しています。逆に、バックエンドの負荷が高いにもかかわらずアイドル接続が多い場合は、アイドルウィンドウが長すぎるか、ワーカーが不足していることを示唆しています。私は変更点を個別に切り出し、一度に1つの調整項目のみをテストし、バーストフェーズやバックグラウンド負荷が適切に反映されるよう、測定を十分な時間実行します。そうすることで、タイムアウト、キャッシュ、バックエンド間の捉えにくい相互作用さえも、確実に解きほぐすことができます。.

経済的な視点：日常生活における費用対効果

KeepAliveTimeout が1秒長くなるごとに、プロセスやメモリのリソースを消費する可能性がありますが、その一方でTCP／TLSのオーバーヘッドを「削減」し、レイテンシを低減します。私はこれを投資判断と捉えています。APIについては、負荷のピーク時でもスループットを高く維持できるよう、どちらかといえば控えめな設定を選択します。一方、従来のウェブサイトについては、ページ表示速度を測定可能なレベルで向上させるために、わずかなアイドル予算を割り当てます。アセットドメインについては、モニタリング結果や予備容量がそれを明確に裏付ける場合にのみ、この予算を増やします。この冷静なバランス感覚により、誤った方向への過剰最適化を防ぎ、ベンチマーク上でだけ輝いて終わることなく、改善効果が再現可能になるようにしています。.

WordPressとホスティング環境の概要

WordPressスタックは、キャッシュ、動的なPHPリクエスト、そして多くの機能を組み合わせたものです。資産, そのため、最初の設定として3～5秒のタイムアウト範囲を設定するのが有効です。同時負荷が高い場合は、ワーカーをより早く解放できるよう、2～3秒に短縮します。さらにCDNが稼働している場合は、状況が変わります。オリジンへのリクエストが少ない場合、タイムアウト値を多少長く設定しても問題ありません。マネージド環境では、プロバイダーがEvent-MPMを採用し、適切なMaxKeepAliveRequestsとグローバルタイムアウトを設定しているかを確認するようにしています。こうした細部にまで配慮したサービスは、ユーザー体験を著しく向上させます。多くのプロジェクトにおいて、webhoster.deは適しています。なぜなら、ここでは パフォーマンス-チューニングと適切な設定が重要な役割を果たす。.

簡単にまとめると

私はたいていKeepAliveを有効にしておき、わずかな タイムアウト, 、これにより接続が適切に再利用されるようにしています。APIには2～3秒、一般的なウェブサイトには3～5秒、リソースが十分に確保されている場合はアセットドメインには5～10秒を設定しています。 MaxKeepAliveRequestsはパターンに合わせて調整し、その効果を定期的に確認しています。Event-MPM、適切なグローバルタイムアウト、そして体系的なモニタリングによって、結果を確実に保証しています。微調整、明確な指標、そして徹底したテストを行うことで、確実にパフォーマンスの向上につながります。 パフォーマンス そして、レイテンシの低減。これにより、安定性やリソース消費に悪影響を与えることなく、高い効率を実現しています。.