ネットワーク遅延：100メガビットと1ギガビット

現在の接続が100MビットのWebサーバーがあり、プロバイダーが1Gbitへのアップグレードを提供しています。これはスループットを意味することを理解していますが、パケットが大きいほど、より速くパケットを送信できるため、応答時間（pingなど）がわずかに減少すると予想されます。誰かがこれをベンチマークしたことがありますか？

30バイトの負荷の例（100メガビットから100メガビットのサーバー）：

> ping server -i0.05 -c200 -s30
[...]
200 packets transmitted, 200 received, 0% packet loss, time 9948ms
rtt min/avg/max/mdev = 0.093/0.164/0.960/0.093 ms

例（100メガビットから100メガビットのサーバー）で300バイトの負荷（MTU未満）：

> ping server -i0.05 -c200 -s300
[...]
200 packets transmitted, 200 received, 0% packet loss, time 10037ms
rtt min/avg/max/mdev = 0.235/0.395/0.841/0.078 ms

30から300までの平均 遅延は0.164から0.395に増加します-これは、1gibtから1gbitへの接続の場合、ゆっくりと増加すると予想されます。パケット全体を受信するまで最初に待機するスイッチを介して接続している場合、100メガビットから1ギガビットまでの速度が期待できます。

更新：回答に対するコメントを注意深く読んでください！接続は飽和状態ではなく、この速度の増加は1つのリクエストに対して人間にとって重要ではないと思いますが、それは多くのリクエスト（Redis、データベースなど）を追加することです。

@LatinSuDからの回答について：

> ping server -i0.05 -c200 -s1400
200 packets transmitted, 200 received, 0% packet loss, time 9958ms
rtt min/avg/max/mdev = 0.662/0.866/1.557/0.110 ms

現在の100Mbitリンクが飽和状態になっている場合のみ、レイテンシーが大幅に低下します。飽和していない場合、変化に気付かないでしょう。

さらに、1Gbitリンクがより大きなパケットをサポートできるという仮定は間違っています。最大パケットサイズは、パケットがたどるパスに沿ったさまざまなデバイスのMTUによって決まります。サーバーのNICから始めて、顧客のコンピューターのMTUに至るまでです。内部LANアプリケーション（パスに沿ってすべてのデバイスを制御できる場合）では、MTUを増やすことができる場合がありますが、この状況では、デフォルトのMTUである1500にかなりとどまっています。その結果、それらは断片化され、それにより実際にパフォーマンスが低下します。

YES gbitのレイテンシは次のとおりです。

• 同じバイト数を高速で転送できます

ただし、パケットのサイズが一定の場合にのみ改善が認められます。

• 56バイトパッケージ=>実質的に高速転送なし
• 1000バイトパッケージ=> 20％高速な転送
• 20000バイトパッケージ=> 80％高速な転送

したがって、レイテンシに非常に敏感なアプリケーション（4ms対0.8ms、20kbの往復）があり、より大きなパッケージを転送する必要がある場合、100mbitからgbitに切り替えると、平均で100メガビット/秒よりもはるかに少ない（=リンクが永続的に飽和していない）。

サーバー（100mbit）->スイッチ（gbit）->サーバー（100mbit）：

size: 56 :: rtt min/avg/max/mdev = 0.124/0.176/0.627/0.052 ms
size: 100 :: rtt min/avg/max/mdev = 0.131/0.380/1.165/0.073 ms
size: 300 :: rtt min/avg/max/mdev = 0.311/0.463/2.387/0.115 ms
size: 800 :: rtt min/avg/max/mdev = 0.511/0.665/1.012/0.055 ms
size: 1000 :: rtt min/avg/max/mdev = 0.560/0.747/1.393/0.058 ms
size: 1200 :: rtt min/avg/max/mdev = 0.640/0.830/2.478/0.104 ms
size: 1492 :: rtt min/avg/max/mdev = 0.717/0.782/1.514/0.055 ms
size: 1800 :: rtt min/avg/max/mdev = 0.831/0.953/1.363/0.055 ms
size: 5000 :: rtt min/avg/max/mdev = 1.352/1.458/2.269/0.073 ms
size: 20000 :: rtt min/avg/max/mdev = 3.856/3.974/5.058/0.123 ms

サーバー（gbit）->スイッチ（gbit）->サーバー（gbit）：

size: 56 :: rtt min/avg/max/mdev = 0.073/0.144/0.267/0.038 ms
size: 100 :: rtt min/avg/max/mdev = 0.129/0.501/0.630/0.074 ms
size: 300 :: rtt min/avg/max/mdev = 0.185/0.514/0.650/0.072 ms
size: 800 :: rtt min/avg/max/mdev = 0.201/0.583/0.792/0.079 ms
size: 1000 :: rtt min/avg/max/mdev = 0.204/0.609/0.748/0.078 ms
size: 1200 :: rtt min/avg/max/mdev = 0.220/0.621/0.746/0.080 ms
size: 1492 :: rtt min/avg/max/mdev = 0.256/0.343/0.487/0.043 ms
size: 1800 :: rtt min/avg/max/mdev = 0.311/0.672/0.815/0.079 ms
size: 5000 :: rtt min/avg/max/mdev = 0.347/0.556/0.803/0.048 ms
size: 20000 :: rtt min/avg/max/mdev = 0.620/0.813/1.222/0.122 ms

= 複数のサーバーで平均20kb pingで80％のレイテンシー削減

（リンクの1つだけがgbitである場合、20kb pingのレイテンシーは5％削減されます。）

帯域幅の遅延と「速度」について根本的な誤解があると思います。速度は帯域幅と遅延の関数です。たとえば、到着するのに3日かかる全国に出荷されたDVDのデータの出荷を検討してください。インターネット経由でデータを送信することと比較してください。インターネットのレイテンシー接続ははるかに短くなっていますが、接続の「速度」を出荷に合わせるには、1秒あたり9.6MBで受信する必要があります（このソースからの参照例）。

あなたの場合、より高い帯域幅にアップグレードすると、より多くの同時ユーザーにサービスを提供できますが、個々のユーザーへのレイテンシーは改善されません。

あなたはピンホールを通して世界を見ています。異なる速度での遅延の違いの有効なテストは、クロスコネクトケーブルで接続された2つの同一のNIC間です。10MB、100MB、および1000MBの速度を計算するNICを設定します。これは、さまざまな速度でレイテンシに実質的に違いがないことを示します。使用されている最大帯域幅に関係なく、すべてのパケットは同じワイヤ速度で移動します。ストアアンドフォワードキャッシュを使用してスイッチを追加すると、すべてが変更されます。スイッチを介した遅延のテストは、スイッチへの接続を2つだけにして行う必要があります。その他のトラフィックは、テストの遅延に影響する場合があります。その場合でも、スイッチはログをロールオーバーしたり、パケットタイプカウンターを調整したり、内部クロックを更新したりできます。

あり 他のどの変更よりも、ドライバーの違いによるpingレイテンシの大きな変化を見てきました。帯域幅、スイッチ、NICのオフロードなど。

このスイッチは、単一送信テストのストアアンドフォワードよりも大幅に高速なカットスルーを備えた次の大きな変更です。ただし、適切に設計されたストアアンドフォワードスイッチは、高負荷時の全体的なパフォーマンスにおいてカットスルースイッチを追い越す可能性があります。ギガビットの初期には、安価なギガビットスイッチよりもレイテンシが低い10MBの高性能バックプレーンスイッチを見てきました。

Pingテストは、インターネットを使用する場合のパフォーマンス分析には実質的に無関係です。これらは、テストの瞬間にトランスポートで何が起こっているかを簡単に把握するための簡単なテストです。実稼働パフォーマンスのテストは、pingを実行するよりもはるかに複雑です。高性能スイッチはコンピューターであり、高負荷下では動作が異なります-遅延の変化。

NICを遅くしたり、NICを低速に設定したりすると、スイッチキャッシュを使用してサーバーへの入力を調整することで、同時バーストのあるサーバーを実際に助けることができます。1回の再送信で、待ち時間の減少が打ち消される場合があります。通常、単一のpingテストではなく、中〜高負荷のトラフィックレベルが重要です。例えば、古い低速のSun Ultrasparc（1回のpingのレイテンシーが高い）は、100％の帯域幅負荷が70％未満の場合、開発サーバーとして使用される新しい安価なギガビットデスクトップよりも優れています。デスクトップには、より高速なgb NIC、より高速な接続gb-gb、より高速なメモリ、より多くのメモリ、より高速なディスク、より高速なプロセッサが搭載されていますが、チューニングされたサーバークラスのハードウェア/ソフトウェアと同様に動作しません。これは、gb-gbを実行している現在のチューニングされたサーバーが古いハードウェアよりも高速ではなく、より大きなスループット負荷を処理できると言っているわけではありません。「」の質問にはさらに複雑さがあります

プロバイダーが100 MB接続と1 GB接続で異なるスイッチを使用しているかどうかを調べます。同じスイッチバックプレーンを使用している場合、トラフィックレベルが低い帯域幅を超えた場合にのみ増加分を支払うことになります。そうしないと、短時間で他の多くのユーザーがギガビットに切り替えられ、古いスイッチに残った少数のユーザーのパフォーマンスが向上します-スイッチの高負荷時の待ち時間が短くなります（サーバーだけでなく、スイッチ全体の負荷） ）。

リンゴとオレンジの例：ローカルISPは、バンドルされたサービス、DSL、電話に新しいスイッチを提供しました。当初、ユーザーはパフォーマンスの向上を見ました。システムが売られすぎました。これで、古いスイッチを使用しているユーザーのパフォーマンスが安定します。深夜には、新しいシステムのユーザーは高速になります。夕方、高負荷のもとで、古いスイッチクライアントは明らかに新しい過負荷システムよりも優れています。

遅延が短いと、配信が速くなるとは限りません。1つのページを提供する20のリクエストでMySQlに言及しています。そのトラフィックは、ページ要求と同じNICにあるべきではありません。すべての内部トラフィックを内部ネットワークに移動すると、発信NICでの衝突と総パケット数が減少し、単一パケットの.04msの遅延ゲインよりも大きなゲインが提供されます。ページあたりのリクエスト数を減らして、ページの読み込み遅延を減らします。ページ、html、css、javascript、画像を圧縮して、ページの読み込み時間を短縮します。これらの3つの変更により、.04ミリ秒の遅延削減のために使用されていない帯域幅を支払うよりも継続的に大きな全体的な利益が得られます。pingは24時間実行し、実際の遅延の変化を確認するために平均化する必要があります。スマートスイッチは、初期帯域幅のわずかな増加と大きな転送の抑制により、適応RTSPタイプの調整を行います。ページサイズ（グラフィック、大きなhtml / css / javascript）に応じて、初期接続の遅延/帯域幅は、大きなページまたは全ページの転送よりもはるかに低い/高い場合があります。ページの一部がストリーミングされている場合、ページとストリームのパフォーマンスが大幅に異なる場合があります。

300バイトのパケットを想定してみましょう（使用-s 300する場合、実際にはヘッダーのために大きくなります）。

300 bytes = 2400 bits
2400 bits / 100Mbit/sec = 0.024ms

0.024msは、フレームの送信に必要なほぼ実際の時間です（メディアアクセス時間もヘッダーもカウントしません）。

ピンポンシーケンスでは、その時間の2倍（0.048ms）に加えて、OSがクエリを処理するための時間がかかります。

それはあなたの待ち時間がいくつかのオーバーヘッド要因の90％によって引き起こされることを私に意味します。Gbとの間に大きな違いがあるかどうかはわかりません。おそらく1ミリ秒未満の違いはWebサーバーでは顕著ではありません。

とにかく、1400バイトのような本当に大きなパケットで試すことができますか？

これは、接続しているスイッチのタイプによって異なります。一部のベンダー（Criscoなど）では、ICMPパケットはCPU（gag）に戻ります。

より良いテストは、100Mbpsおよび1Gbpsリンクを使用してホスト間テストを実行することです（つまり、ホストからスイッチまたはホストからルーターへのテストではない）。

一日の終わりに、遅延はスイッチの転送速度とスイッチのアーキテクチャの詳細（ASICがボードに配置される場所、ラインカード間のロックの処理方法など）にまで低下します。テストを頑張ってください。