ベースライン バージョン: パフォーマンスが非常に低いアプリケーション

  • [アーティクル]

更新プログラムの計算に使用される最初のパフォーマンスの低いコード サンプルは次のとおりです。

注意

わかりやすくするために、次の例ではエラー処理はありません。 運用アプリケーションは常に戻り値をチェックします。

 

警告

アプリケーションの最初のいくつかの例では、コードの変更によって可能なパフォーマンスの向上を示すために、意図的にパフォーマンスが低下します。 アプリケーションでこれらのコード サンプルを使用しないでください。これらは例示のみを目的としています。

 

#include <windows.h>

BOOL Map[ROWS][COLS];

void LifeUpdate()
{
    ComputeNext( Map );
    for( int i = 0 ; i < ROWS ; ++i )     //serialized
        for( int j = 0 ; j < COLS ; ++j )
            Set( i, j, Map[i][j] );    //chatty
}

BYTE Set(row, col, bAlive)
{
    SOCKET s = socket(...);
    BYTE byRet = 0;
    setsockopt( s, SO_SNDBUF, &Zero, sizeof(int) );
    bind( s, ... );
    connect( s, ... );
    send( s, &row, 1 );
    send( s, &col, 1 );
    send( s, &bAlive, 1 );
    recv( s, &byRet, 1 );
    closesocket( s );
    return byRet;
}

この状態では、アプリケーションのネットワーク パフォーマンスが最も悪い可能性があります。 このバージョンのサンプル アプリケーションに関する問題は次のとおりです。

  • アプリケーションはおしゃべりです。 各トランザクションが小さすぎます。セルを 1 つずつ更新する必要はありません。
  • セルを同時に更新できる場合でも、トランザクションは厳密にシリアル化されます。
  • 送信バッファーは 0 に設定され、アプリケーションでは送信ごとに 200 ミリ秒の遅延が発生します (セルあたり 3 回)。
  • アプリケーションは非常に重く接続され、セルごとに 1 回接続されます。 TIME-WAIT 状態のため、アプリケーションは特定の宛先の 1 秒あたりの接続数に制限されますが、各トランザクションの所要時間は 600 ミリ秒を超えるので、ここでは問題ではありません。
  • アプリケーションは脂肪です。多くのセルは更新から更新に変更されないため、多くのトランザクションはサーバーの状態に影響しません。
  • このアプリケーションは、低品質のストリーミングを示します。小さな送信では、CPU と RAM が大量に消費されます。
  • アプリケーションは、その送信に対してリトル エンディアン表現を想定しています。 これは、現在の Windows プラットフォームでは当然の想定ですが、有効期間の長いコードでは危険な場合があります。

主要なパフォーマンス メトリック

次のパフォーマンス メトリックは、ラウンド トリップ時間 (RTT)、Goodput、プロトコルオーバーヘッドで表されます。 これらの用語の説明については、 ネットワーク用語 に関するトピックを参照してください。

  • 単一セル更新のセル時間(ネットワーク時間)には、Nagle と遅延 ACK の相互作用に 4*RTT + 600 ミリ秒が必要です。
  • Goodput は 6 バイト未満です。
  • プロトコルのオーバーヘッドは 99.6% です。

低速アプリケーションの改善

ネットワーク用語

リビジョン 1: 明らかなのクリーンアップ

リビジョン 2: より少ない接続の再設計

リビジョン 3: 圧縮ブロック送信

今後の機能強化