リビジョン 1: 明らかな をクリーンアップする
このバージョンのサンプル プログラムでは、パフォーマンスの向上に最初の進歩を遂げることになるいくつかの明らかな変更が行われています。 このバージョンのコードはパフォーマンスチューニングから遠く離れていますが、段階的に改善されたアプローチの効果を調べることが可能な適切な増分ステップです。
警告
このアプリケーションの例では、コードの変更によって可能なパフォーマンスの向上を示すために、意図的にパフォーマンスが低下します。 このコード サンプルは、アプリケーションでは使用しないでください。これは説明のみを目的としています。
#include <windows.h>
BYTE Set(row, col, bAlive)
{
SOCKET s = socket(...);
BYTE byRet = 0;
BYTE tmp[3];
tmp[0] = (BYTE)row;
tmp[1] = (BYTE)col;
tmp[2] = (BYTE)bAlive;
bind( s, ... );
connect( s, ... );
send( s, &tmp, 3 );
recv( s, &byRet, 1 );
closesocket( s );
return byRet;
}
このバージョンの変更点
このバージョンには、次の変更が反映されています。
- SNDBUF=0 を削除しました。 バッファーなし送信と遅延受信確認による 200 ミリ秒の遅延が削除されます。
- Send-Send-Receive 動作を削除しました。 この変更により、Nagle と遅延 ACK の相互作用による 200 ミリ秒の遅延が排除されます。
- リトル エンディアンの仮定を削除しました。 バイトは順に並べ替えることができるようになりました。
残りの問題
このバージョンでは、次の問題が残ります。
- アプリケーションは引き続き接続が多い。 600 ミリ秒以上の遅延が取り除かれるため、アプリケーションは 1 秒あたり 12 回の接続の持続レートに達するようになりました。 多くの同時接続が問題になりました。
- アプリケーションはまだ脂肪です。変更されていないセルは引き続きサーバーに伝達されます。
- アプリケーションは依然として低いストリーミングを示しています。3 バイトの送信はまだ小さい送信です。
- アプリケーションは、直接接続されたイーサネットで 4 KB/秒に等しい 2 バイト/RTT を送信するようになりました。 これは高速ではありませんが、TIME-WAIT が最初に問題を引き起こす可能性があります。
- オーバーヘッドは 99.3% まで低下しますが、それでも十分なオーバーヘッドの割合ではありません。
主要なパフォーマンス メトリック
次の主要なパフォーマンス メトリックは、ラウンド トリップ時間 (RTT)、Goodput、およびプロトコルオーバーヘッドで表されます。 これらの用語の説明については、 ネットワーク用語 に関するトピックを参照してください。
このバージョンには、次のパフォーマンス メトリックが反映されています。
- セル時間 — 2×RTT
- Goodput — 2 バイト/RTT
- プロトコルのオーバーヘッド — 99.3%
関連トピック