Partager via

La version de référence : une application très peu performante

  • Article

L’exemple de code initial et peu performant utilisé pour calculer les mises à jour est le suivant :

Notes

Par souci de simplicité, il n’existe aucune gestion des erreurs dans les exemples suivants. Toute application de production vérifie toujours les valeurs de retour.

 

Avertissement

Les premiers exemples de l’application fournissent 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 ; elles sont à des fins 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 a les pires performances réseau possibles. Les problèmes liés à cette version de l’exemple d’application sont les suivants :

  • L’application est bavard. Chaque transaction est trop petite : les cellules n’ont pas besoin d’être mises à jour 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, trois fois par cellule.
  • L’application est très connectée, se connectant une fois pour chaque cellule. Les applications sont limitées dans le nombre de connexions par seconde pour une destination donnée en raison de l’état TIME-WAIT, mais ce n’est pas un problème ici, car chaque transaction prend plus de 600 millisecondes.
  • L’application est grasse; de nombreuses transactions n’ont aucun effet sur l’état du serveur, car de nombreuses cellules ne passent pas de la mise à jour à la mise à jour.
  • L’application présente une diffusion en continu médiocre ; les envois de petite taille consomment beaucoup de processeur et de RAM.
  • L’application suppose une représentation peu endienne pour ses envois. Il s’agit d’une hypothèse naturelle pour la plateforme Windows actuelle, mais elle peut être dangereuse pour le code à longue durée de vie.

Métriques de performances clés

Les métriques de performances suivantes sont exprimées en temps d’aller-retour (RTT), Goodput et Surcharge de protocole. Pour obtenir une explication de ces termes, consultez la rubrique Terminologie du réseau .

  • Temps de cellule, temps réseau pour une mise à jour d’une seule cellule, nécessite 4* RTT + 600 millisecondes pour Nagle et des interactions ACK retardées.
  • Goodput est inférieur à 6 octets.
  • La surcharge de protocole est de 99,6 %.

Amélioration d’une application lente

Terminologie réseau

Révision 1 : Nettoyage de l’évidence

Révision 2 : Refonte pour moins de connexions

Révision 3 : Envoi de blocs compressés

Améliorations futures