大規模なRTTで1GbpsサーバーからのTCPスループットが100Mbpsサーバーよりも低い
インフラストラクチャは、シンガポール、ロンドン、ロサンゼルスなど、世界中のいくつかの主要な場所に分散しています。2つの場所間のRTTは150ms以上です。 最近、すべてのサーバーを1Gbpsリンクを使用するようにアップグレードしました（100Mbpsから）。私たちはさまざまな場所にあるサーバー間でいくつかのTCPベースのテストを実行しており、いくつかの驚くべき結果を見てきました。これらの結果は完全に再現可能です。 ロサンゼルス（100Mbps）からロンドン（100Mbps）：〜96Mbpsスループット ロサンゼルス（100Mbps）からロンドン（1Gbps）：〜96Mbpsスループット ロサンゼルス（1Gbps）からロンドン（100Mbps）：10-40Mbpsスループット（揮発性） ロサンゼルス（1Gbps）からロンドン（1Gbps）：10-40Mbpsスループット（揮発性） ロサンゼルス（1Gbps）からロサンゼルス（1Gbps）：900Mbpsを超えるスループット 送信側が1Gbpsで実行されている場合は常に、長いリンクではスループットが大幅に低下するようです。 以前のテストアプローチは非常に単純です-私はcURLを使用してターゲットサーバーから1GBのバイナリをダウンロードしています（上記の場合、cURLクライアントはロンドンのサーバーで実行され、LAからダウンロードするため、LAが送信者になります）。 。もちろん、これは単一のTCP接続を使用しています。 iperfを使用してUDPで同じテストを繰り返すと、問題が解消します。 ロサンゼルス（100Mbps）からロンドン（100Mbps）：〜96Mbpsスループット ロサンゼルス（100Mbps）からロンドン（1Gbps）：〜96Mbpsスループット ロサンゼルス（1Gbps）からロンドン（100Mbps）：〜96Mbpsスループット ロサンゼルス（1Gbps）からロンドン（1Gbps）：250Mbpsを超えるスループット これは、私の目にあるTCPまたはNIC /ポート構成の問題を直視しています。 両方のサーバーは、TCPキュービックでCentOS 6.xを実行しています。どちらも最大8MBのTCP送受信ウィンドウがあり、TCPタイムスタンプと選択的確認応答が有効になっています。すべてのテストケースで同じTCP構成が使用されます。完全なTCP構成は以下のとおりです。 net.core.somaxconn = 128 net.core.xfrm_aevent_etime = 10 net.core.xfrm_aevent_rseqth = 2 net.core.xfrm_larval_drop = 1 net.core.xfrm_acq_expires = 30 net.core.wmem_max = 8388608 net.core.rmem_max = 8388608 net.core.wmem_default = 131072 net.core.rmem_default = 131072 net.core.dev_weight = 64 net.core.netdev_max_backlog …