我々のアプリケーションをELBの背後に置くApache 2.4を実行している従来のサーバクラスタがあります。このELBには、1つのHTTPと1つのHTTPSという2つのリスナーがあり、ELBで終端し、通常のHTTPトラフィックをその後ろのインスタンスに送信します。このELBはまた、事前開放がオフになっている（それは、忙しい労働者の蓄積を引き起こしていた）。通常の負荷では、インスタンスごとに1〜3人のビジー状態のワーカーがあります。mod_proxy_protocolまたはELBがApacheのワーカー数を増加させる原因は何ですか？
新しいELBの後ろに移行しようとしている新しいサーバークラスタがあります。この移行の目的は、何千ものドメインへのSNIサービングTLSトラフィックを許可することです。したがって、このクラスタは、ELBレベルで有効になっているmod_proxy_protocolを使用します。テストの目的で、トラフィックの30％を新しいロードバランサに送信するために、DNS（ルート53）レベルでトラフィックに重みを付けました。この小さな負荷の下でも、5〜10人の忙しい労働者があり、トラフィックが増えるにつれて成長します。
さらなるテストとして、これらの新しいインスタンスの1つ（proxy_protocolを無効にして）を新しいELBから古いELBに移動しました。作業者数は平均レベルに落ちました。これは、ELB（HTTPとTCPの処理の違い？）またはmod_proxy_protocolに問題があることを示しているようです。
私の質問：プロキシプロトコルと新しいELBを使用すると、なぜ2倍のビジー状態のApacheの作業者がいるのですか？私は、TCPリスナーがダムしてトラフィックを処理しないので、より速く、その結果、トラフィックを積極的に「変更」するHTTPリスナーよりも労働時間が短縮されると考えています。
この問題の診断に役立つガイダンスは高く評価されています。
洞察をいただきありがとうございます。このようにレイアウトされていると、ブラウザがワーカーを開いたままにしていることがわかり、ELBがHTTPルーティングを実行するときにELBがそれを緩和していたことは間違いありません。私たちはELBの後ろに〜18台のサーバを持っていて、インスタンスレベルで再利用される可能性が低いと考えてキープ・アライブをオフにしました。提案されているようにHAProxyを見て、接続の再利用を扱う方法を再評価します。 – Andrew
さらに、開かれていない作業員のビルドの問題は、サポートチケットで処理されました。私たちは、事前開封のオン/オフがサポートチケットを取ることを前提にして、時間を割いていないため、問題を診断することはできませんでした。 VPCに移行したときに、EC2 classicから（そして同時にApache 2.2から2.4へ）移行しました。 VPC ELBは、労働者にRの「読書要求」状態を構築させ、めったに閉鎖しなかった。最終的に私たちのワーカーはすべてR状態になり、Apacheは設定したmax_workersの数に関係なく、さらにトラフィックを拒否し始めます。 AWSのサポートやグーグルリングで何かが出てきた – Andrew
「リクエストを読んでいる」ということで、Apacheが無期限に立ち往生しているのは興味深い。 Apacheは接続を終了していなければなりません。そうしないとELBは最終的に（おそらくタイムアウトの後に）それらを閉じてしまいます。 HAProxyマシンの私の標準設定は 'timeout http-request 60000'（60秒）を使い、その後、プロキシはこれらの余分な接続を閉じます。私はHAProxyをしばらく使っていますが、この点については、私がこの値にどのようにして到着したか、あるいはこれが私の側で高く設定されているかどうかを実験したかどうかを実際には思い出せません。私は好奇心からそれを試す必要があるかもしれません。 –