TP 2 de dimensionnement de réseaux

Transcription

1 Bourdin Benoit Courtat Julien TP 2 de dimensionnement de réseaux Exercice 1 Tout au long de TP, nous avons du utiliser httperf. Nous tirons nos résultats de la sortie standart du logiciel, mais aussi d'un moniteur système. Pour cela, nous avons utilisé ksysgard, avec l'enregistrement de l'activité CPU, mémoire et entrées/sorties (du disque dur) dans des fichiers de journaux. Exercice 2 Pour cet exercice, on aura donc travaillé par groupe de 2: un injecteur et un serveur web. On fera 2 téléchargements avec httperf: un gros fichier (1Mo) et un petit (quelques Ko), le tout une seule fois (une seule requête). 3) Coté client : Petit fichier ~5Ko durée du test: s temps de réponse 1: 0.8 ms temps d'établissement de connection TCP: 2 ms nombre de requêtes générées par secondes: temps de réponse 2: 0.9 ms taille en-tête http: 279 Bytes, du contenu : Bytes débit moyen: Kb/s nombre d'erreurs: 0

2 Gros fichier ~1Mo durée du test : s temps de réponse 1: 0.8 ms temps d'établissement de connection TCP: ms nombre de requêtes générées par secondes: 9.9 temps de réponse 2: 99.5 ms taille en-tête http: 265 Bytes, du contenu : Bytes débit moyen: Kb/s nombre d'erreurs: 0 4) La moyenne consiste en la somme des temps de réponse pour chaque requete, divisé par le nombre de requetes total. La médiane nécessite un tri préalable des valeurs des temps de réponse, puis de prendre la n/2 ième valeur si on admet que n est le nombre de requetes envoyées. Mathématiquement, la signification de la moyenne et de la médiane n'est donc pas la même. La moyenne indiquant le temps de réponse moyen, alors que la médiane indique un temps de réponse d'une valeur située au milieu d'un ensemble ordonné. 5) 1er test On obtient au niveau du serveur, dans les fichiers de journaux : [25/Feb/2005:10:49: ] "GET / tmp/track01minnesanger.wav HTTP/1.1" "-" "httperf/0.8" Le fichier a bien été téléchargé (code retour HTTP 200), avec la bonne taille (de o). Au niveau des moniteurs systèmes du serveur, on a : fév 25 10:49:46 localhost disk/3:0/total: 11 fév 25 10:49:43 localhost cpu0/sys: 1 Enfin, on ne constate aucun changement au niveau de la mémoire consommée. 2eme test Pour ce 2eme test, on ne constate pas plus de particularités par rapport au premier [25/Feb/2005:10:54: ] "GET / tmp/ballademusicale.html HTTP/1.1" "-" "httperf/0.8" fév 25 10:54:46 localhost disk/3:0/total: 10

3 Exercice 3 Pour cet exercice, on aura fait une série de tests sur lesquels on mesure : le temps de réponse moyen le nombre d'erreurs le débit la charge CPU le nombre d'accès disque l'utilisation de la mémoire Pour chacun de ces tests, on obtient des résultats que l'on aura stoqué puis mis en graphique. On obtient les résultats suivants : débit en fonction du nombre de connexions nombre de connexions Debit Gros Fichier Debit Petit Fichier débit en Kb/s Nombre d'erreurs en fct du nombre de connexions taux d'erreur 90,00% 85,00% 80,00% 75,00% 70,00% 65,00% 60,00% 55,00% 50,00% 45,00% 40,00% 35,00% 30,00% 25,00% 20,00% 15,00% 10,00% 5,00% 0,00% Nb Erreurs Gros Fichier Nb Erreurs Petit Fichier nombre de connexions par sec

4 temps de réponse en fonction du nombre de connexions temps de réponse en ms Tps Rep Moy Gros fichier Tps Rep Moy GF nombre de connexions par secondes nombre d'accès au disque en fct du nombre de connexions utilisation de la mémoire en fct du nombre de connexions

5 charge cpu en fct du nombre de connexions Goulot d'étranglement Ce qui apparaît limiter la performance du système est à la fois le processeur du client (étant à 100% dans la plupart des tests) et le nombre de clients maximum au niveau du serveur (MAX_CLIENT), qui est fixée à 150 dans notre cas. On voit d'ailleurs sur les graphiques que le comportement est différent avant et après 150 clients. Loi de Little La loi précise : N = lambda * R On cherche ici N, le nombre moyen de connexions en parallèle en cours. 150 connections/s durant 20 s, petit fichier: On a lambda, valant 150 connexions/s On a R, valant 1.9 ms On obtient N= 150 * = << MAX_CLIENTS on ne constate d'ailleurs pas d'erreurs. 150 connections/s durant 20 s, gros fichier: On a lambda, valant 6.1 connexions/s On a R, valant ms On obtient N= 345 > MAX_CLIENTS d'où le fait que l'on ai beaucoup d'erreurs(65%). 300 connections/s durant 20 s, petit fichier: On a lambda, valant 300 connexions/s On a R, valant 1.9 ms On obtient N= 300* = 0.57 << MAX_CLIENTS on ne constate d'ailleurs pas d'erreurs.

6 300 connections/s durant 20 s, gros fichier: On a lambda, valant 6.3 connexions/s On a R, valant ms On obtient N= 354 > MAX_CLIENTS d'où le fait que l'on ai beaucoup d'erreurs( 83%). 500 connections/s durant 20 s, petit fichier: On a lambda, valant 500 connexions/s On a R, valant 2.4 ms On obtient N= 500* = 1.2 << MAX_CLIENTS on ne constate d'ailleurs pas d'erreurs. 500 connections/s durant 20 s, gros fichier: On a lambda, valant 6.5 connexions/s On a R, valant ms On obtient N= 375 > MAX_CLIENTS d'où le fait que l'on ai beaucoup d'erreurs( 90%). On peut en conclure que plus le nombre de connexions en parallèle augmente et plus le temps de connexion est allongé. A partir du moment où on dépasse le nombre de connexions permis par la valeur MAX_CLIENTS ( ici à 256) le taux d'erreur devient vite conséquent. La solution à ce problème de goulot d'étranglement est de rajouter plusieurs injecteurs et de changer la valeur de MAX_CLIENTS dans la configuration d'apache (pour l'augmenter). Exercice 4 Après avoir lancé le test avec 6 clients lancant en parallèle (à la suite pour faire une montée de charge progressive) un httperf, on obtient au niveau du serveur les performances suivantes :

7 taux d'occupation du cpu en fonction du temps(les paliers observés correspondent à l'activation d'un client httperf) quantité de mémoire utilisée en fonction du temps

8 nombre d'accès au disque dur en fonction du temps 2) On voit bien grossièrement sur ces graphiques, que plus la charge augmente, plus la charge du serveur augmente. Cependant, il ne nous a pas été possible de faire beaucoup plus. En effet, nous avons cherché à saturer le serveur, mais ce n'a pas été possible avec nos 6 injecteurs. Lorsque nous avons essayé avec plus, apache ne voulait plus fonctionner et nous avons été obligé de redémarrer plusieurs fois la machine. Bref, nous n'avons pas pu avoir des mesures précises. Nous n'avons donc pas pu saturer le serveur du moins au niveau des ressources consommée sur la machine. 3) Nous pensons que si nous n'avons pas pu engorger le serveur, c'est a cause de la valeur MAX_CLIENT du serveur apache. Hors cette denière était fixée à 256 lors du test, ce qui est le maximum qu'autorise apache dans la version installée. Peut être avec une valeur supérieure à 256 aurions nous pu saturer le serveur apache. 4) La problématique posée par notre méthodologie est la réduction à 2 du nombre des fichiers téléchargés, ce qui permet au serveur de mettre ces fichiers en cache mémoire voir processeur et permet d'augmenter les performances du serveur. Un vrai site web devrait posséder bien plus de deux fichiers consulté majoritairement par les internautes. Ce qui complexifie la mise en cache de ces fichiers par le serveur et implique une perte de performances. De plus, les requetes proviennent toujours des mêmes 6 machines, hors on ne sait pas comment apache gère les connections répétées provenant de la meme adresse ip.