ラックスペースとcentosでのロードバランサーのパフォーマンスが低い
負荷分散のさまざまなオプションの負荷テストを行っていますが、Nginx、haproxy、varnishの結果が良くありません。 Rackspaceに4GBのロードバランサーが1つあり、4x1GBのアプリサーバーにアクセスしています。
応答する前に意図的に500ms待機する「/ slow」というURLをヒットしています。アプリケーションサーバーに直接アクセスすると、1秒あたり1600〜1800の接続速度を処理できます。
Nginxロードバランサーをヒットした場合、約2000の接続しか処理できません。 4x1600 = 6000に近いものを期待していました。以下は、テストに使用しているコマンドです。これは、40個の256MBインスタンスで並行して実行されます。接続のパフォーマンスを確認したいので、意図的にnum_callを1に設定しています。これより高くなると、多くのエラーが発生し始めます。
httperf --server 50.56.80.227 --port 1555 --uri /slow --rate 50 --num-call 1 --num-conn 100 --timeout 5
これが私のnginx設定です： https://Gist.github.com/1299501
したがって、これは奇妙なことです。nginx、haproxy、varnishのいずれを使用しても、ほぼ同じ結果が得られます。ただし、Rackspaceの新しいクラウドバランサーをテストしたところ、パフォーマンスが大幅に向上しました（7000/sで正常に動作します）。 nginxなどはすべて私が設定したインスタンスで実行されており、ラックスペースバランサーは実行されていないため、システムに問題があると推測されます。自分が制御するバランサーを使用したいので、キャッシュ、gzip、sslなどを追加できます。
ボトルネックが何であるかをどのように知ることができますか？パフォーマンスを向上させるためにシステムを微調整する必要があるものはありますか？ 4GB以上のRAMが必要ですか？ （テスト中のRAM使用量は高くありません）。他のランダムなアイデアはありますか？
更新：バランサーのサイズを8GBに変更したところ、最大6000〜7000、またはラックスペースバランサーと同等のパフォーマンスが大幅に向上しました。以前はRAM）が不足していなかったため、これは意味がありません。
更新：これは、バランサーをオーバーロードしたときのhttperfからの出力の例です（8GBバージョンでは、以前よりも高くなっていますが、エラーは似ています）： https://Gist.github.com/1299628
私もRackspaceCloudを使用していますが、非常によく似た問題があります。問題はこれだと思います：
あなたが説明していることから、ラックスペースが提供する哀れな量の帯域幅を単純に最大化しており、Varnish/Nginxのような驚くべきパフォーマンスの向上をほぼ完全に実現しているように見えます。
確認するには、iftopを開いた状態でベンチマークの一部を再実行し、各サーバーサイズでラックスペースが提供する量に完全に制限されるのを確認します。