Version de référence : une application très médiocre

L’exemple de code initial le plus médiocre utilisé pour calculer les mises à jour est le suivant :

Notes

Par souci de simplicité, il n’y a pas de gestion des erreurs dans les exemples suivants. Toutes les applications de production vérifient toujours les valeurs de retour.

Avertissement

Les premiers exemples de l’application offrent des performances intentionnellement médiocres, afin d’illustrer les améliorations de performances possibles avec les modifications apportées au code. N’utilisez pas ces exemples de code dans votre application. ils sont fournis à titre d’illustration uniquement.

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

Dans cet État, l’application présente les pires performances réseau possibles. Les problèmes liés à cette version de l’exemple d’application sont les suivants :

  • L’application est bavarde. Chaque transaction est trop petite : il n’est pas nécessaire de mettre à jour les cellules une par une.
  • Les transactions sont strictement sérialisées, même si les cellules peuvent être mises à jour simultanément.
  • La mémoire tampon d’envoi est définie sur zéro, et l’application entraîne un délai de 200 millisecondes pour chaque envoi, soit trois fois par cellule.
  • L’application est très connectée et se connecte une seule fois pour chaque cellule. Les applications sont limitées en nombre de connexions par seconde pour une destination donnée en raison de l’état d’attente, mais ce n’est pas un problème dans la mesure où chaque transaction prend plus de 600 millisecondes.
  • L’application est FAT ; de nombreuses transactions n’ont aucun effet sur l’état du serveur, car de nombreuses cellules ne changent pas de la mise à jour à la mise à jour.
  • L’application présente une mauvaise diffusion. les petits envois consomment beaucoup d’UC et de RAM.
  • L’application suppose une représentation Little endian pour ses envois. Il s’agit d’une hypothèse naturelle pour la plate-forme Windows actuelle, mais elle peut être dangereuse pour le code à long terme.

Principales mesures de performance

Les mesures de performances suivantes sont exprimées en temps de boucle (RTT), Goodput et surcharge de protocole. Pour obtenir une explication de ces termes, consultez la rubrique terminologie réseau .

  • L’heure de la cellule, l’heure réseau pour une mise à jour de cellule unique, requiert 4 temps * RTT + 600 millisecondes pour Nagle et les interactions ACK différées.
  • Goodput est inférieur à 6 octets.
  • La surcharge de protocole est de 99,6%.

Amélioration d’une application lente

Terminologie du réseau

Révision 1 : nettoyage évident

Révision 2 : reconception pour des connexions moins nombreuses

Révision 3 : envoi de bloc compressé

Améliorations futures