これはネットワーク帯域幅のボトルネックを証明していますか？
内部ABテストでは、サーバーが1秒あたり3kヒットで1kの同時実行を処理できると誤って想定していました。
現時点での私の理論は、ネットワークがボトルネックであるというものです。サーバーは十分な速度で十分なデータを送信できません。
Blitz.ioからの1k同時実行での外部テストでは、ヒット数が180で上限に達し、サーバーが1秒あたり180しか返すことができないため、ページの応答に時間がかかることが示されています。
私はnginxから空のファイルを提供し、それをベンチに入れました：それは並行性で1：1にスケーリングします。
IO/memcachedのボトルネック（nginxは通常memcachedからプルします）を除外するために、ファイルシステムからキャッシュされたページの静的バージョンを提供します。
結果は私の元のテストと非常に似ています。上限は約180RPSです。
HTMLページを半分に分割するとRPSが2倍になるため、ページのサイズによって確実に制限されます。
ローカルサーバーから内部的にApacheBenchを使用すると、高い転送速度で、フルページとハーフページの両方で約4kRPSの一貫した結果が得られます。転送速度：62586.14 [キロバイト/秒]を受信
外部サーバーからABを実行すると、約180RPSが得られます。これはblitz.ioの結果と同じです。
意図的なスロットルではないことをどうやって知ることができますか？
複数の外部サーバーからベンチマークを実行すると、すべての結果が悪くなり、ベンチマークサーバー/ blitz.ioのダウンロード速度の問題ではなく、MYサーバーの送信トラフィックに問題があると思われます。
したがって、サーバーが十分な速度でデータを送信できないという結論に戻ります。
私は正しいですか？このデータを解釈する他の方法はありますか？複数のサーバーをセットアップするためのソリューション/最適化+それぞれが毎秒180ヒットを処理できる負荷分散ですか？
私はサーバーの最適化にまったく慣れていないので、このデータを解釈する確認をいただければ幸いです。
アウトバウンドトラフィック
アウトバウンド帯域幅の詳細は次のとおりです。ネットワークグラフは、16 Mb/sの最大出力（16メガビット/秒）を示しています。あまり聞こえません。
スロットルについての提案のために、私はこれを調べて、linodeが50mbpsのキャップを持っていることを発見しました（明らかに、私はヒットにさえ近づいていません）。 100mbpsに上げてもらいました。
Linodeは私のトラフィックを制限し、私はそれを打っていないので、これは私のサーバーが実際に最大100mbpsを出力できるはずであるが、他の内部ボトルネックによって制限されていることを意味しますか？この大規模なネットワークがどのように機能するのか理解できません。彼らは文字通りHDDから読み取ることができるのと同じくらい速くデータを送ることができますか？ネットワークパイプthatは大きいですか？
結論として
1：上記に基づいて、LBの背後にあるサーバーごとに正確に180RPSでマルチnginxサーバーセットアップの上にnginxロードバランサーを追加することで、確実に180RPSを上げることができると思います。
2：linodeに50/100mbitの制限があり、まったく到達していない場合は、単一サーバーのセットアップでその制限に到達するためにできることがあるはずです。ローカルで十分な速度でデータの読み取り/送信ができ、linodeが50mbit/100mbitの上限を設定するのに苦労している場合は、検出方法がわからない上限に達することができない内部ボトルネックが存在する必要があります。正しい？
質問は今では巨大で曖昧であることに気づきましたが、それをどのように要約するかはわかりません。私が行った結論については、どんな意見でも歓迎します。
問題は、linode.comのグラフのピークが真のピークであると想定していたことです。グラフは5分の平均データポイントを使用していることがわかりました。したがって、実際に50メガビットの上限に達したときに、ピークは24メガバイトであるように見えました。
彼らがそれを100mbitsに上げたので、私のベンチマークはすぐに新しいアウトバウンドトラフィック制限に達しました。
以前に気づいたら！私の推論の多くは、そのグラフのためにアウトバウンドトラフィックの制限に達していないという考えに基づいていました。
現在、私は1秒あたり370リクエストでピークに達します。これは、100 mbpsのすぐ下で、リクエストの「バックログ」を取得し始め、応答時間が増加し始めます。
ページを縮小することで、最大同時実行性を増やすことができます。 gzipを有効にすると、600RPSが得られます。
突然ピークに達し、保留中のリクエストのバックログ（帯域幅によって制限される）が蓄積し始めると、まだ問題が発生しますが、それは別の質問のように聞こえます。
これは、最適化/このデータの読み取り/考えられる問題の絞り込みにおける素晴らしい教訓でした。ご意見ありがとうございました！
あなたがそれを理解したので少し遅れました...しかし多分あなたは時々ServerFaultブログを読むことを検討するべきです。
私は特にこの投稿について考えています 、ここで彼らはなぜ1秒ポーリング間隔は、あなたが持っていたものと非常によく似た問題に関連して、時々それをカットしません。
1 Gbit/sのインターフェイスで、わずか10〜30 MBit/sの速度でパケットをかなり頻繁に破棄していることがわかりました。これにより、パフォーマンスが低下します。これは、10〜30 MBit/sのレートが、実際には5分あたりに転送されるビット数であり、1秒のレートに変換されるためです。 Wiresharkを詳しく調べて、1ミリ秒IOグラフを使用すると、いわゆる1 Gbit/sインターフェイスの1ミリ秒あたり1Mbitのレートが頻繁にバーストすることがわかりました。
確かに私は考えさせられました。そして、私が最初に得たチャンスは、私の店の他のSAでそれを無効にしていることを知っています。この問題が発生すると、ひどく見事で知覚的に見えます。
誰が知っている、私はそれらのいくつかを秘密にするかもしれません。 :)
ネットワークによって制限される場合がありますが、必ずしも単に帯域幅の問題であるとは限りません。リモートテストユニットの遅延は、任意の時点で保留中の接続の数（50ミリ秒の確認応答の待機はローカルの0.5ミリ秒とは大きく異なります）、および接続の進行に伴うウィンドウサイズのネゴシエーションと安定化に影響します。また、輻輳の関数として、またはキャリア（またはアップストリーム）の帯域幅制限のメカニズムとして、ある程度のパケット損失にさらされる可能性があります。
賢明なベースラインを描くために、方程式から可能な限り排除することをお勧めします。サーバーから一般的なインターネット上のいくつかのポイントまでのピーク帯域幅、遅延、およびパケット損失を測定します。聞こえるかもしれませんが、「Voipトラフィックテスト」などを検索してみてください。 VOIPサービスのいくつかのプロバイダーは、これらの種類のパターンをかなりの精度で（双方向に）測定できるアプリを持っています。リンクの実際の有用な速度に関するいくつかの有効な経験的データが得られたら、結果は十分に検証される可能性があります。
帯域幅テストに加えて、標準以下のWebトラフィックのパケットキャプチャを調べて、過剰な数の再送信を探したり、サーバーが要求に応答するのにかかっている見かけの時間を測定したりすることも役立つ場合があります（この場合値は接続数の関数として大幅に増加しています。これは大きな手がかりです）。