Révision 1 : Nettoyage de l’évidence
Dans cette version de l’exemple de programme, quelques modifications évidentes ont été apportées pour améliorer les performances. Cette version du code est loin d’être optimisée pour les performances, mais il s’agit d’une bonne étape incrémentielle qui permet d’examiner les effets d’approches incrémentiellement meilleures.
Avertissement
Cet exemple de l’application fournit des performances intentionnellement médiocres, afin d’illustrer les améliorations de performances possibles avec les modifications apportées au code. N’utilisez pas cet exemple de code dans votre application ; c’est à titre d’illustration uniquement.
#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;
}
Modifications apportées à cette version
Cette version reflète les modifications suivantes :
- Suppression de SNDBUF=0. Les retards de 200 millisecondes dus aux envois non débogués et aux accusés de réception différés sont supprimés.
- Suppression du comportement Send-Send-Receive. Cette modification élimine les retards de 200 millisecondes dus aux interactions Nagle et ACK retardées.
- Suppression de l’hypothèse little-endian. Les octets sont maintenant dans l’ordre.
Problèmes restants
Dans cette version, les problèmes suivants persistent :
- L’application est toujours fortement connecté. Étant donné que les délais de plus de 600 millisecondes sont supprimés, l’application atteint maintenant le taux soutenu de 12 connexions par seconde. De nombreuses connexions simultanées deviennent maintenant un problème.
- L’application est encore grosse ; les cellules inchangées sont toujours propagées au serveur.
- L’application présente toujours un faible streaming; Les envois de 3 octets sont toujours des envois de petite taille.
- L’application envoie maintenant 2 octets/RTT, ce qui équivaut à 4 Ko/s sur Ethernet directement connecté. Ce n’est pas trop rapide, mais TIME-WAIT provoquera probablement d’abord des problèmes.
- La surcharge est en baisse à 99,3 %, ce qui n’est toujours pas un bon pourcentage de surcharge.
Métriques de performances clés
Les métriques de performances clés 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.
Cette version reflète les métriques de performances suivantes :
- Durée de cellule : 2×RTT
- Goodput : 2 octets/RTT
- Surcharge de protocole : 99,3 %
Rubriques connexes