Revision 1: Bereinigen der offensichtlichen

In dieser Version des Beispiel Programms wurden einige offensichtliche Änderungen vorgenommen, die den ersten Schritten bei der Verbesserung der Leistung in Kauf nehmen. Diese Version des Codes ist weit von der Leistungsoptimierung entfernt. es handelt sich jedoch um einen guten inkrementellen Schritt, der die Untersuchung der Auswirkungen von inkrementellen besseren Ansätzen ermöglicht.

Warnung

Dieses Beispiel für die Anwendung bietet absichtlich eine schlechte Leistung, um mit Codeänderungen mögliche Leistungsverbesserungen zu veranschaulichen. Verwenden Sie dieses Codebeispiel nicht in Ihrer Anwendung. Dies dient nur zur Veranschaulichung.

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

Änderungen in dieser Version

Diese Version spiegelt die folgenden Änderungen wider:

  • "Sndbuf = 0" wurde entfernt. Die 200 Millisekunden Verzögerungen aufgrund von ungepufferten Sende-und verzögerten Bestätigungen werden entfernt.
  • Das Sende-Send-Receive-Verhalten wurde entfernt. Diese Änderung beseitigt 200-Millisekunden-Verzögerungen aufgrund von Nagle-und verzögerten ACK-Interaktionen.
  • Die Little-d-Annahme wurde entfernt. Die Bytes sind nun in der richtigen Reihenfolge.

Verbleibende Probleme

In dieser Version verbleiben die folgenden Probleme:

  • Die Anwendung stellt immer noch eine hohe Verbindung her. Da die Verzögerungen von 600 MS Millisekunden entfernt werden, erreicht die Anwendung jetzt die 12 Verbindungen pro Sekunde. Viele gleichzeitige Verbindungen werden nun zu einem Problem.
  • Die Anwendung ist immer noch FAT. unveränderte Zellen werden weiterhin an den Server weitergegeben.
  • Die Anwendung weist immer noch ein schlechtes Streaming auf. 3-Byte-Sendungen sind immer noch kleine Sende Vorgänge.
  • Die Anwendung sendet jetzt 2 Bytes/RTT, was bei einem direkt verbundenen Ethernet 4 KB/s beträgt. Dies ist nicht zu schnell, aber die Wartezeit führt wahrscheinlich zunächst zu Problemen.
  • Der Aufwand liegt bei bis zu 99,3%, was jedoch immer noch keinen guten Verwaltungs Prozentsatz zur Folge hat.

Wichtige Leistungsmetriken

Die folgenden wichtigen Leistungsmetriken werden in Roundtripzeit (RTT), goodput und Protokoll Mehraufwand ausgedrückt. Eine Erläuterung dieser Begriffe finden Sie im Thema zur Netzwerkterminologie .

Diese Version reflektiert die folgenden Leistungsmetriken:

  • Zellzeit – 2 × RTT
  • Goodput – 2 Bytes/RTT
  • Protokoll Aufwand – 99,3 Prozent

Verbessern einer langsamen Anwendung

Netzwerkterminologie

Baselineversion: eine sehr schlechte leistungsfähige Anwendung

Revision 2: Neuentwerfen für eine geringere Anzahl von Verbindungen

Revision 3: komprimierte Block-Sendevorgang

Zukünftige Verbesserungen