Condividi tramite

Versione di base: un'applicazione con prestazioni molto scarse

  • Articolo

L'esempio di codice iniziale con prestazioni scarse usate per calcolare gli aggiornamenti è il seguente:

Nota

Per semplicità, non esiste alcuna gestione degli errori negli esempi seguenti. Qualsiasi applicazione di produzione controlla sempre i valori restituiti.

 

Avviso

I primi esempi dell'applicazione offrono prestazioni intenzionalmente scarse, per illustrare i miglioramenti delle prestazioni possibili con le modifiche apportate al codice. Non usare questi esempi di codice nell'applicazione; sono solo a scopo illustrativo.

 

#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 questo stato, l'applicazione ha le prestazioni di rete peggiori. I problemi relativi a questa versione dell'applicazione di esempio includono:

  • L'applicazione è chiacchiere. Ogni transazione è troppo piccola. Le celle non devono essere aggiornate una alla sola.
  • Le transazioni vengono serializzate rigorosamente, anche se le celle potrebbero essere aggiornate contemporaneamente.
  • Il buffer di invio è impostato su zero e l'applicazione comporta un ritardo di 200 millisecondi per ogni invio, tre volte per cella.
  • L'applicazione è molto connetti pesante, connettendosi una volta per ogni cella. Le applicazioni sono limitate nel numero di connessioni al secondo per una determinata destinazione a causa dello stato TIME-WAIT, ma questo non è un problema, poiché ogni transazione richiede più di 600 millisecondi.
  • L'applicazione è grassa; molte transazioni non hanno alcun effetto sullo stato del server, perché molte celle non cambiano dall'aggiornamento all'aggiornamento.
  • L'applicazione presenta scarsi flussi; piccoli invii consumano un sacco di CPU e RAM.
  • L'applicazione presuppone una rappresentazione little-endian per i relativi invii. Si tratta di un presupposto naturale per la piattaforma Windows corrente, ma può essere pericoloso per il codice di lunga durata.

Metriche delle prestazioni chiave

Le metriche delle prestazioni seguenti sono espresse in Round Trip Time (RTT), Goodput e Protocol Overhead. Per una spiegazione di questi termini, vedere l'argomento Terminologia di rete .

  • Il tempo di cella, il tempo di rete per un singolo aggiornamento della cella, richiede 4*RTT + 600 millisecondi per le interazioni Nagle e ACK ritardato.
  • Goodput è minore di 6 byte.
  • Il sovraccarico del protocollo è del 99,6%.

Miglioramento di un'applicazione lenta

Terminologia di rete

Revisione 1: Pulizia dell'ovvio

Revisione 2: Riprogettazione per un minor numero di connessione

Revisione 3: Invio di blocchi compressi

Miglioramenti futuri