ネットワーク遅延：100Mbit対1Gbit
現在の接続が100Mbitの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
例（100mbit〜100mbitサーバー）で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に増加します。これは、1ギガバイトから1ギガビットの接続の場合、これはゆっくりと増加すると予想されます。パケット全体を受信するまで最初に待機するスイッチを介して接続する場合は、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
はい、以下の理由により、レイテンシは低くなります。
- 同じバイト数をより高速に転送できます
しかし、パケットが特定のサイズである場合、改善は相当程度です。
- 56バイトのパッケージ=>実質的に高速な転送はありません
- 1000バイトのパッケージ=> 20％速い転送
- 20000バイトのパッケージ=> 80％高速な転送
したがって、アプリケーションがレイテンシに非常に敏感（4ms vs. 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
= 複数のサーバーで平均すると、20 kbのpingで80％のレイテンシ削減
（リンクの1つだけがgbitの場合でも、20 kbのpingで5％の遅延が削減されます。）
レイテンシが大幅に低下する唯一の方法は、現在の100Mbitリンクが飽和している場合です。飽和していないと、変化に気付かないでしょう。
さらに、1ギガビットリンクがより大きなパケットをサポートできるという仮定は正しくありません。最大パケットサイズは、パケットが通過するパスに沿ったさまざまなデバイスのMTUによって決定されます-サーバー上のNICから始まり、顧客のコンピューターのMTUまで続きます。内部LANアプリケーション（パス上のすべてのデバイスを制御している場合）では、MTUを増やすことが可能な場合がありますが、この状況では、デフォルトのMTU 1500でかなり行き詰まっています。それより大きなパケットを送信すると、 、それらは断片化してしまい、実際にはパフォーマンスが低下します。
帯域幅の待ち時間と「速度」について根本的な誤解があると思います。速度は帯域幅と遅延の関数です。たとえば、全国に発送されたDVDのデータが到着するまでに3日かかると考えてください。それをインターネットを介してデータを送信することと比較してください。インターネットのレイテンシー接続ははるかに低くなっていますが、接続の「速度」を出荷に一致させるには、毎秒9.6MB（ このソースからの参照例 ）で受信する必要があります。
あなたの場合、より高い帯域幅にアップグレードすると、より多くの同時ユーザーにサービスを提供できますが、個々のユーザーの待ち時間は改善されません。
あなたはピンホールを通して世界を見ています。異なる速度での遅延差の有効なテストは、クロスコネクトケーブルで接続された2つの同一のNIC間で行われます。 NICの演算速度を10mb、100mb、1000mbに設定します。これは、異なる速度でレイテンシに実質的に差がないことを示しています。使用されている最大帯域幅に関係なく、すべてのパケットは同じワイヤ速度で移動します。ストアとフォワードキャッシュを備えたスイッチを追加すると、すべての変更が変更されます。スイッチを介したレイテンシのテストは、スイッチへの2つの接続のみで実行する必要があります。他のトラフィックはテストのレイテンシに影響を与える可能性があります。その場合でも、スイッチはログのロールオーバー、パケットタイプカウンターの調整、内部クロックの更新などを行う場合があります。すべてが遅延に影響する場合があります。
はい、ハードウェアの変更、NICの違い、スイッチの違い、ドライバーの違いにより、100mbから1gbへの切り替えの方が速い（レイテンシが低い）場合があります。ドライバーの違いによるpingレイテンシの変化が他のどの変化よりも大きくなっています。帯域幅、スイッチ、NICのオフロードなど。
スイッチは、シングルトランスミッションテストのストアアンドフォワードよりも大幅に高速なカットスルーを備えた、次の最大の変更となります。ただし、適切に設計されたストアアンドフォワードスイッチは、高負荷時に全体的なパフォーマンスでカットスルースイッチを追い越す場合があります。ギガビットの初期の頃は、安価なギガビットスイッチよりもレイテンシが低い10 mbの高性能バックプレーンスイッチを目にしました。
Pingテストは、インターネットを使用する場合のパフォーマンス分析には実質的に無関係です。これらは、テストの瞬間にトランスポートで何が起こっているかについての大まかなアイデアを得るための簡単なテストです。本番パフォーマンステストは、単なるpingよりもはるかに複雑です。高性能スイッチはコンピューターであり、高負荷下では動作が異なります-待ち時間の変化。
低速のNICを使用するか、NICを低速に設定すると、スイッチキャッシュを使用してサーバーへの入力を調整することにより、サーバーでバーストを同時に発生させることができます。 1回の再送信で、レイテンシの低下をなくすことができます。通常、中程度から高負荷のトラフィックレベルが重要であり、単一のpingテストではありません。例えば古い低速のUltraUltrasparc（単一のpingの待ち時間が長い）は、帯域幅の負荷が70％未満の場合、開発サーバーとして使用される新しい安価なギガビットデスクトップよりも優れています。デスクトップはより高速なgb NIC、より高速な接続gb-gb、より高速なメモリ、より多くのメモリ、より高速なディスク、より高速なプロセッサを備えていますが、サーバークラスのハードウェア/ソフトウェアと同様に機能しません。これは、gb-gbを実行している現在の調整済みサーバーが古いハードウェアよりも速くなく、より大きなスループットの負荷を処理できると言っているのではありません。 「より高いパフォーマンス」の問題は、あなたが尋ねているように思えるほど複雑です。
プロバイダーが100MB接続と1GB接続に異なるスイッチを使用しているかどうかを確認します。彼らが同じスイッチバックプレーンを使用する場合、トラフィックレベルが低い帯域幅を超えた場合にのみ、増加分を支払うことになります。そうしないと、短時間で他の多くのユーザーがギガビットに切り替わり、古いスイッチを離れた数人のユーザーがより高いパフォーマンスを発揮するようになります-スイッチの高負荷時（サーバーだけでなく、全体的なスイッチ負荷） ）。
リンゴとオレンジの例：ローカルISPは、バンドルされたサービス、DSL、および電話用の新しいスイッチを提供しました。当初、ユーザーはパフォーマンスの向上を見ました。システムが売られすぎました。これで、古いスイッチを使用しているユーザーは、一貫したパフォーマンスが向上します。深夜の間、新しいシステムのユーザーはより速くなります。高負荷下での夕方には、古いスイッチクライアントは明らかに新しい過負荷システムよりも性能が優れています。
レイテンシの低下は、配信の高速化に必ずしも相関するとは限りません。 1つのページを提供するための20のリクエストでMySQlについて言及しています。そのトラフィックは、ページリクエストと同じNICにあるべきではありません。すべての内部トラフィックを内部ネットワークに移動すると、衝突と発信NICでの合計パケット数が減少し、単一パケットの.04msレイテンシゲインよりも大きなゲインが得られます。ページあたりのリクエスト数を減らして、ページの読み込み待ち時間を減らします。ページの読み込み時間を短縮するために、ページ、html、css、javascript、画像を圧縮します。これらの3つの変更により、0.04ミリ秒のレイテンシを削減するために使用されていない帯域幅を支払うよりも、全体的に大きな利益が得られます。実際の遅延の変化を確認するには、pingを24時間実行して平均化する必要があります。スマートスイッチは、アダプティブRTSPタイプのスロットルを行うようになり、初期帯域幅の増加が小さくなり、大きな転送が抑制されます。ページサイズ（グラフィック、大きなhtml/css/javascript）に応じて、大きな接続または全ページ転送よりも初期接続の待ち時間/帯域幅がはるかに低い/高い場合があります。ページの一部がストリーミングしている場合、ページとストリームのパフォーマンスが大幅に異なる場合があります。
これは、接続しているスイッチのタイプによって異なります。一部のベンダー（Criscoなど）では、ICMPパケットがCPU（gag）に逆流します。
100 Mbpsおよび1 Gbpsリンクを使用してホスト間テストを実行することをお勧めします（つまり、ホストからスイッチまたはホストからルーターへのテストではありません）。
1日の終わりに、レイテンシはスイッチの転送速度とスイッチのアーキテクチャの詳細（ASICがボードに配置されている場所、ラインカード間のロックの処理方法など）にまで下がります。テストで頑張ってください。
300バイトのパケットを想定しましょう（-s 300ヘッダーがあるため、実際には大きくなります。
300 bytes = 2400 bits
2400 bits / 100Mbit/sec = 0.024ms
0.024msは、フレームを送信するのに必要なおよその実際の時間です（メディアアクセス時間やヘッダーは含まれません）。
ピンポンシーケンスでは、その2倍の時間（0.048ms）に加えて、OSがクエリを処理する時間もかかります。
つまり、レイテンシはいくつかのオーバーヘッド要因の90％が原因で発生します。 Gbと大きな違いがあるかどうかはわかりません。おそらく1ミリ秒未満の差は、ウェブサーバーでは目立ちません。
とにかく、1400バイトのような非常に大きなパケットを試してみませんか？