私の内部ABテストは、サーバーが1秒あたり3kヒットで1kの同時実行を処理できることを意味すると誤って想定していました。

現時点での私の理論は、ネットワークがボトルネックであるということです。サーバーは十分な速度で十分なデータを送信できません。

1kの同時実行でのblitz.ioからの外部テストでは、サーバーが1秒あたり180しか返せないため、ページの応答時間が長くなるにつれて、ヒット/秒が180で上限に達することが示されています。

私はnginxから空のファイルを提供し、それをベンチに入れました：それは並行性で1：1にスケーリングします。

IO / memcachedのボトルネック（nginxは通常memcachedからプルします）を排除するために、ファイルシステムからキャッシュされたページの静的バージョンを提供します。

結果は元のテストと非常に似ています。約180 RPSに制限されています。

HTMLページを半分に分割すると、RPSが2倍になるため、ページのサイズによって制限されます。

ローカルサーバーから内部的にApacheBenchを実行すると、フルページとハーフページの両方で、高い転送レートで約4k RPSの一貫した結果が得られます。転送速度：62586.14 [Kバイト/秒]受信

外部サーバーからABにアクセスすると、約180RPSになります-blitz.ioの結果と同じです。

意図的なスロットルではないことをどのように確認できますか？

複数の外部サーバーからベンチマークを実行すると、すべての結果が悪くなり、ベンチマークサーバー/ blitz.ioのダウンロード速度の問題ではなく、MYサーバーのアウトバウンドトラフィックに問題があると思われます。

だから、サーバーが十分な速度でデータを送信できないという結論に戻りました。

私は正しいですか？このデータを解釈する他の方法はありますか？毎秒180ヒットを処理できる複数のサーバーと負荷分散をセットアップするソリューション/最適化ですか？

私はサーバーの最適化にかなり慣れていないので、このデータを解釈する確認をいただければ幸いです。

アウトバウンドトラフィック

アウトバウンド帯域幅についての詳細は次のとおりです。ネットワークグラフには、16 Mb / sの最大出力：16メガビット/秒が表示されます。全然聞こえない。

スロットルについての提案のため、私はこれを調べて、linodeのキャップが50 Mbpsであることを発見しました（明らかに、ヒットに近づいていません）。100 Mbpsに上げました。

linodeはトラフィックを制限し、ヒットさえしませんので、これは私のサーバーが実際に最大100mbpsを出力できるはずですが、他の内部ボトルネックによって制限されることを意味しますか？私はこの大規模なネットワークがどのように機能するのか理解していない。文字通り、HDDから読み取れる速度でデータを送信できますか？ネットワークパイプはそれほど大きいですか？

結論として

1：上記に基づいて、LBの背後にあるサーバーごとに正確に180RPSのマルチnginxサーバーセットアップの上にnginxロードバランサーを追加することで、180RPSを確実に上げることができると考えています。

2：linodeに50 / 100mbitの制限があり、それがまったくヒットしない場合は、単一のサーバーセットアップでその制限にヒットするためにできることがあるはずです。ローカルで十分な速さでデータの読み取り/送信ができ、linodeが50mbit / 100mbitのキャップを持つことさえ気にする場合、検出する方法がわからないキャップをヒットできない内部ボトルネックが存在する必要があります。正しい？

この質問は今や巨大で曖昧なものであることに気づきましたが、それをどのように凝縮するのかわかりません。私が行った結論については、ご意見をお寄せください。

問題は、linode.comのグラフピークが真のピークであると仮定したことです。グラフは5分間の平均データポイントを使用しているため、実際には50メガビットの上限に達したときにピークが24メガビットであるように見えました。

彼らが100メガビットに引き上げたので、私のベンチマークはすぐに新しいアウトバウンドトラフィック制限に達しました。

もっと早く気づいたなら！私の推論の多くは、そのグラフのためにアウトバウンドのトラフィック制限に達していないという考えにかかっていました。

今、私は毎秒370リクエストでピークに達し、これはリクエストの「バックログ」の取得を開始する100mbpsのすぐ下であり、応答時間が増加し始めます。

ページを縮小することにより、最大同時実行性を高めることができます。gzipを有効にすると、600RPSになります。

突然ピークに達し、保留中の要求（帯域幅によって制限される）のバックログが蓄積し始めると、まだ問題に遭遇しますが、それは別の質問のように聞こえます。

これは、最適化/このデータの読み取り/起こりうる問題の絞り込みにおける素晴らしいレッスンでした。ご意見ありがとうございます！

あなたはそれを理解したので少し遅れました...しかし、多分あなたは時々ServerFaultブログを読むことを考慮すべきです。

私は特にこの投稿について考えています。彼らはあなたが持っていたものと非常に類似した問題に関連して、1秒のポーリング間隔を設けても時々それをカットしない理由を議論しています。

1 Gbit / sのインターフェイスでは、10〜30 MBit / sのレートでかなり頻繁にパケットを破棄しており、パフォーマンスが低下していることがわかりました。これは、10〜30 MBit / sのレートが実際には1秒のレートに変換された5分あたりの転送ビット数だからです。Wiresharkを詳しく調べて、1ミリ秒のIOグラフを使用すると、いわゆる1 Gbit / sインターフェイスの1ミリ秒あたり1メガビットのレートが頻繁にバーストすることがわかりました。

確かに考えさせられました。そして、私が知っているのは、私が店で他のSAに最初に出会った最初のチャンスを破壊していることを知っていることです。

誰が知っているだろう、私はそれらのいくつかを秘密にさえ許すかもしれない。:)

ネットワークによって制限される場合がありますが、必ずしも帯域幅の問題ではありません。リモートテストユニットの待機時間は、任意の時点で保留中の接続の数に影響を与えます（確認応答の50ミリ秒の待機は、ローカルでの.5ミリ秒とは大きく異なります）。また、輻輳の関数として、または通信事業者（またはアップストリーム）の帯域幅制限のメカニズムとして、ある程度のパケット損失にさらされる可能性があります。

合理的なベースラインを描くために、方程式から可能な限り削除することをお勧めします。サーバーから一般的なインターネット上のいくつかのポイントまでのピーク帯域幅、遅延、およびパケット損失を測定します。ありそうにないかもしれませんが、「Voip traffic test」などを検索してみてください。VOIPサービスのいくつかのプロバイダーは、これらの種類のパターンを（双方向で）かなりの精度で測定できるアプリを持っています。リンクの実際の有用な速度に関する有効な経験的データを取得したら、結果を検証することができます。

帯域幅テストに加えて、サブパーWebトラフィックのパケットキャプチャを調べて、過剰な再送信回数を調べたり、サーバーがリクエストに応答するのにかかっている見かけの時間を測定したりすることも役立ちます（..if値は接続数の関数として大幅に増加しています。これは大きな手がかりです。