Test des performances

Carlos Benavides Ricardo Soares Ribolli

Description de l’infrastructure de test

Les tests ont été faits sur deux machines virtuelles Debian, chacune dans une machine
hôte différente. La machine virtuelle du serveur possède 4 GB de mémoire, processeur
2.3 GHz Intel i5, et la machine client possède 2 GB de mémoire, processeur 2.3 GHz
Intel i5. Les machines étaient connéctées à un réseaux WiFi 802.11 b/g/n mixte, qui peut
atteindre des vitesses jusqu’à 300 M bps.

Compréhension des scénarios

4.2.1.
1000 ms
n= = 20 iter
50 ms

4.2.2. Étant donné que le boucle est censé effectuer 20 itérations par seconde, et sur chaque
itération il y a une instruction client.send(), le client est censé envoyer 20 requêtes par
seconde.
4.2.3. L’hypothèse que doit être fait sur le temps de réponse du serveur est qu’il est
strictement inférieur à 50 ms. Dans le cas où cette hypothèse ne soit pas respectée, le
client reste attendant la réponse jusqu’à la recevoir ou arriver à un timeout.
4.2.4. En considérant que les deux instructions sont vues comme des actions, et le client
est censé faire 20 itérations par seconde, donc 20 client.send() et 20 client.receive()
qui donnent un total de 40 actions par seconde.
4.2.5.
— Le paquet envoyé par le client est perdu avant d’arriver au serveur.
— La réponse envoyée par le serveur est perdue avant d’arriver au client.
— Le temps de calcul écoulé dans le serveur est plus grand que le timeout de 5
secondes.
4.2.6. Le profil de charges a une durée de 1 minute, c’est-à-dire que les utilisateurs peuvent
envoyer des instructions dans l’intervalle entre 0 et 1 minute. Supposons qu’un utilisateur
envoie une requête send juste avant la fin du profil, dans t = 1 minute. Alors, cette
requête peut durer jusqu’à 5 secondes, donc nous pouvons donner une borne supérieure
de 1 minute et 5 secondes à la durée d’éxecution.

1
Premier test (1 utilisateur virtuel local)

action type calls min max mean median std dev throughput errors
LOG 0 NaN NaN NaN NaN NaN NaN 116
UDP CONNECT 1 200 200 200 200 NaN NaN 0
UDP RECEIVE 1164 16 50334 588.375 39 1804.829 19.458 0
UDP SEND 1164 40 10273 734.783 699 897.248 19.456 0
GLOBAL LOAD 2329 16 50334 661.381 425 1426.512 38.925 116

Figure 1 – Synthèse statistique obtenue pour le test avec un utilisateur virtuel local

4.3.1. Dans ce cas où il n’y a ni latence réseau, ni contention ni délais de file d’attente,
nous pouvons imaginer que le temps de traitement moyen d’une requête receive résulte
du temps d’exécution de la commande send.receive() ajouté au temps de calcul du
serveur.
4.3.2. Si les requête ont un temps de traitement minimum de 16 µs, obtenu à partir du
test local (figure 1, champs min pour le UDP Receive), nous pouvons en déduire que le
serveur a un débit moyen théorique de 1/(16 × 10−6 ) = 62500 requetes/s
4.3.3. Étant donnée que un utilisateur virtuel peut envoyer en moyenne 19.458 requetes/s,
le serveur pourrait admettre au maximum n = b62500/19.458c = 3212 utilisateurs.
4.3.4. Étant donnée que chaque requête du type UDP Receive prend en moyenne 588.375 µs
pour être traitée, et que il y a eu 1164 appels à cette action, le serveur a été utilisée pour
1164∗588.375 µs = 0.685s. Dans une fenêtre de 1 s, cela correspond à un taux d’utilisation
de 68, 5%
4.3.5. Cette simulation a eu 116 erreurs de 1164 requêtes reçues, ce qui fait un taux
d’erreur de 9, 965%.

Deuxième test (1 utilisateur virtuel distant)

action type calls min max mean median std dev throughput errors
LOG 0 NaN NaN NaN NaN NaN NaN 112
UDP CONNECT 1 115 115 115 115 NaN NaN 0
UDP RECEIVE 1127 14 429515 7147.919 5081 15999.494 18.831 0
UDP SEND 1127 67 1716 151.226 127 92.921 18.831 0
GLOBAL LOAD 2255 14 429515 3648.005 1223 11837.509 37.676 112

Figure 2 – Synthèse statistique obtenue pour le test avec un utilisateur virtuel distant

4.4.1. En utilisant le temps de traitement estimé précédemment, on peut calculer la latence

moyenne comme treceive total − ttraitement = 7147.919 µs − 588.375 µs = 6559.544 µs

2
Troisième test (20 utilisateurs virtuels distants)

action type calls min max mean median std dev throughput errors
LOG 0 NaN NaN NaN NaN NaN NaN 1042
UDP CONNECT 20 32 277 71.05 57 53.986 10.776 0
UDP RECEIVE 10420 792 410212 8977.004 6776 12134.979 168.559 144
UDP SEND 10564 8 4529 122.084 98 113.056 170.889 0
GLOBAL LOAD 21004 8 410212 4514.926 472 9625.976 339.755 1186

Figure 3 – Synthèse statistique obtenue pour le test avec 20 utilisateurs virtuels distants

4.5.1. Le temps de réponse moyen pour 20 utilisateurs continue à être UDP RECEIVE,
qui est de 8977.004 µs
4.5.2. Avec la supposition que le temps de latence est fixe, nous pouvons utiliser celui que
nous avons calculé précédemment, qui est de 6559.544 µs. De cette façon, le temps de
traitement du serveur pour 20 utilisateurs est de treceive total − latence = 8977.004 µs −
6559.544 µs = 2417.46 µs. Par rapport a celui avec un seul utilisateurs, l’ajout de 19
utilisateurs résulte en une augmentation de environ 4 fois (a = 2417.46/588.375 = 4.109).
4.5.3. Pendant cette simulation 1042 erreurs de calculs ont été faites de 10420 requêtes
reçues, ce qui représente un taux d’erreur de 10%.
4.5.4. En plus des erreurs de calculs, pendant la simulation 144 erreurs de transmission
sont arrivées. Ces erreurs peuvent être résultat de : soit la perte du paquet lors de l’envoi
ou la réception, soit par timeout de calcul, soit par overflow du buffer du serveur.

Quatrième test (40 utilisateurs virtuels distants)

4.6.1. Le quatrième test ne fonctionne pas à cause d’une limitation de la JVM. Pendant
la création des jobs il y a un moment où la JVM ne peut plus créer des connexions
UDP, donc elle lance l’exception maximum number of Datagram Sockets reached, du type
SocketException.
4.6.2. Pour pouvoir injecter cette charge, il faudra changer la flag Dsun.net.maxDatagram
Sockets de la JVM.

Note
Suite à une confusion lors de la création des équipes en Teide, nous nous sommes inscrits
de manière séparée sur le deux TP qu’on voulait faire : celui-ci comme principal et celui
d’IHM comme supplémentaire. Nous allons rendre ce rapport avec l’équipe de Teide qui
est composé seulement par Carlos Benavides, mais nous voulons que la note soit tenue
en compte pour les deux. Nous sommes désolés en avance pour les inconvénients que cela
peut causer.