Freigeben über

Die Baselineversion: Eine Anwendung mit sehr schlechter Leistung

Das anfängliche Codebeispiel mit schlechter Leistung, das zum Berechnen der Updates verwendet wird, lautet wie folgt:

Hinweis

Der Einfachheit halber gibt es in den folgenden Beispielen keine Fehlerbehandlung. Jede Produktionsanwendung überprüft immer Rückgabewerte.

 

Warnung

Die ersten Beispiele der Anwendung bieten absichtlich schlechte Leistung, um leistungsverbesserungen zu veranschaulichen, die mit Änderungen am Code möglich sind. Verwenden Sie diese Codebeispiele nicht in Ihrer Anwendung. sie dienen nur zur Veranschaulichung.

 

#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;
}

In diesem Zustand weist die Anwendung die schlechteste Netzwerkleistung auf. Zu den Problemen mit dieser Version der Beispielanwendung gehören:

  • Die Anwendung ist unübersichtlich. Jede Transaktion ist zu klein – Zellen müssen nicht einzeln aktualisiert werden.
  • Die Transaktionen werden streng serialisiert, obwohl die Zellen gleichzeitig aktualisiert werden können.
  • Der Sendepuffer ist auf 0 (null) festgelegt, und die Anwendung verursacht eine Verzögerung von 200 Millisekunden für jeden Sendevorgang – dreimal pro Zelle.
  • Die Anwendung ist sehr verbindungsintensiv und stellt für jede Zelle einmal eine Verbindung her. Anwendungen sind in der Anzahl der Verbindungen pro Sekunde für ein bestimmtes Ziel aufgrund des TIME-WAIT-Zustands begrenzt, aber dies ist hier kein Problem, da jede Transaktion über 600 Millisekunden dauert.
  • Die Anwendung ist fett; viele Transaktionen haben keine Auswirkungen auf den Serverstatus, da viele Zellen nicht von Update zu Update wechseln.
  • Die Anwendung weist ein schlechtes Streaming auf. kleine Sendevorgänge verbrauchen viel CPU und RAM.
  • Die Anwendung setzt eine Little-Endian-Darstellung für ihre Sendevorgänge voraus. Dies ist eine natürliche Annahme für die aktuelle Windows-Plattform, kann aber für langlebigen Code gefährlich sein.

Schlüsselleistungsmetriken

Die folgenden Leistungsmetriken werden in Roundtrip time (RTT), Goodput und Protocol Overhead ausgedrückt. Eine Erläuterung dieser Begriffe finden Sie im Thema Netzwerkterminologie .

  • Zellzeit, Netzwerkzeit für ein einzelnes Zellenupdate, erfordert 4 * RTT + 600 Millisekunden für Nagle und verzögerte ACK-Interaktionen.
  • Goodput ist kleiner als 6 Bytes.
  • Der Protokollaufwand beträgt 99,6 %.

Verbessern einer langsamen Anwendung

Netzwerkterminologie

Revision 1: Bereinigen des Offensichtlichen

Revision 2: Neugestaltung für weniger Verbindungen

Revision 3: Komprimiertes Senden von Blocken

Zukünftige Verbesserungen