Temps de réponse max très élevé
chris
cet outil à travers l'excellent blog de Milamber donc merci à lui.
Je souhaite faire des tests de performance sur des serveurs web
apache, mais je ne comprends pas très bien comment Jmeter calcule les
temps de réponse. En effet, durant un test de montée en charge d'un
site web hébergé sur une plateforme relativement puissante, je
constate un temps de réponse max très élevé dans le rapport
consolidé !
TEST 50 VU durant 1 minutes :
Échantillons : 1161
Moyenne : 2706
Min : 208
Max : 51084 <<===================
Ecart Type : 4496,60
Erreur : 0
Débit : 13.3/sec
Ko/sec : 175.13
Moy. octets : 13520
Je n'arrive pas à concevoir que le serveur puisse mettre + de 50
secondes pour répondre à une requête !
Je suis conscient que plus il y a de connexions simultanées plus les
temps de réponse sont longs .... mais là c'est énorme !!
Si je me base sur le temps moyen (2706ms) c'est correct mais il faut
quand même que je prenne en considération les requêtes qui sont
longues, qu'en pensez-vous ?
Est-ce normal d'avoir des temps de réponse aussi longs ?
Voici une capture écran de la fin de mon tableau de résultats :
http://christophe.mayani.free.fr/jmeter/tableau_resultats.jpg
En prenant le détail d'une requête dans l'arbre de résultats, je
compare l'heure de début de l'échantillon avec l'heure à laquelle le
serveur à répondu et je n'arrive pas à en déduire le temps de réponse
indiqué par Jmeter. (exemple dans la capture d'écran ci-dessous).
http://christophe.mayani.free.fr/jmeter/arbre_resultats.jpg
Merci d'avance pour votre aide.
Milamber
Ci-dessous,
Le 04/03/2011 23:51, chris a ecrit :
> Bonjour à tous, je suis nouveau dans l'univers Jmeter. J'ai découvert
> cet outil à travers l'excellent blog de Milamber donc merci à lui.
>
Merci ;-)
> Je souhaite faire des tests de performance sur des serveurs web
> apache, mais je ne comprends pas très bien comment Jmeter calcule les
> temps de réponse. En effet, durant un test de montée en charge d'un
> site web hébergé sur une plateforme relativement puissante, je
> constate un temps de réponse max très élevé dans le rapport
> consolidé !
>
> TEST 50 VU durant 1 minutes :
>
> Échantillons : 1161
> Moyenne : 2706
> Min : 208
> Max : 51084 <<===================
> Ecart Type : 4496,60
> Erreur : 0
> Débit : 13.3/sec
> Ko/sec : 175.13
> Moy. octets : 13520
>
> Je n'arrive pas à concevoir que le serveur puisse mettre + de 50
> secondes pour répondre à une requête !
> Je suis conscient que plus il y a de connexions simultanées plus les
> temps de réponse sont longs .... mais là c'est énorme !!
>
Le problème n'est peut-être pas liée à la puissance de la plateforme.
> Si je me base sur le temps moyen (2706ms) c'est correct mais il faut
> quand même que je prenne en considération les requêtes qui sont
> longues, qu'en pensez-vous ?
>
Oui et non.
Oui car cela peut montrer un problème
Non car il est parfois normal d'avoir quelques requêtes "hors normes"
lors d'un test de charges. C'est pourquoi, il est souvent intéressant de
voir la valeur du 90e centile dans le rapport agrégé.
Si la valeur du 90e centile est proche du temps moyen (2,7s) alors ce
n'est pas très grave, si la valeur 90e est bien supérieure (genre >20s)
alors tu as certainement un problème.
> Est-ce normal d'avoir des temps de réponse aussi longs ?
>
Oui et non. Il faut poser la question à l'équipe de
développement/éditeur et aux administrateurs systèmes.
Mais bon je suppose que non, puisque tu poses la question ;-)
> Voici une capture écran de la fin de mon tableau de résultats :
>
> http://christophe.mayani.free.fr/jmeter/tableau_resultats.jpg
>
> En prenant le détail d'une requête dans l'arbre de résultats, je
> compare l'heure de début de l'échantillon avec l'heure à laquelle le
> serveur à répondu et je n'arrive pas à en déduire le temps de réponse
> indiqué par Jmeter. (exemple dans la capture d'écran ci-dessous).
>
> http://christophe.mayani.free.fr/jmeter/arbre_resultats.jpg
>
Sur cette capture, la première date correspond à la date/heure de début
de la requête coté JMeter. Si tu ajoutes le temps de réponse, tu obtiens
la date/heure de fin.
Donc :
Date de fin = date de début + temps de réponse
Pour la deuxième date (celle dans les entêtes de réponse), il s'agit de
la date du serveur cible. Elle n'est pas utilisée dans les calcul de
temps de réponse de JMeter.
On ne peut pas "déduire" à partir des infos données dans l'arbre de
résultats, le temps de réponses.
Pour aider à comprendre si les longs temps de réponses sont normales ou
non, voici quelles suggestions/remarques :
* Voir le tableau du rapport agrégé et aussi le rapport consolidé,
notamment le 90e centile, l'écart-type, la médiane, le tout par rapport
au temps moyen
* Mettre un récepteur graphique (je sais, il est moche), ne cocher que
"les données" (les points noires) et voir ce que cela donne en termes de
répartitions des temps de réponses
* Ton problème me fait penser à des verrous dans la base de données, (ou
plus généralement à une concurrence d'accès sur une ressource). Les
requêtes au temps de réponses longs attendent quelque chose... (peut
être aussi un pool de connexions saturés?)
* Avec un serveur Apache, tu peux ajouter dans le logs access_log, dans
un format personnalisé, le temps de réponses pour servir la requête d'un
point de vue Apache (%D et %T dans le format de logs
http://httpd.apache.org/docs/2.2/mod/mod_log_config.html#formats ). Tu
peux ainsi avoir le temps en secondes (%T) et/ou le temps en
microsecondes (%D). Ceci pourrait te permettre de vérifier / corroborer
les temps mesurés par JMeter.
A+
Milamber
chris
Tout d'abord merci beaucoup pour ta rapidité et ton efficacité dans ta
réponse :)
J'ai fait de nouveaux tests de charge mais cette fois-ci sur un autre
serveur et un autre site, serveur sur lequel j'ai l'accès root (c'est
mieux, hein :p ?)
Je n'ai pas les accès à la plateforme citée ci-dessus, c'était juste
pour faire un essai.
Sur mon serveur, je constate en faisant le même test de charge (50 VU
pendant 60 secondes) des temps de réponse plutôt longs également (pas
aussi longs que mon exemple d'hier mais pas négligeables pour autant).
En effet, je constate un temps de réponse max de plus de 21 secondes
durant le test, ci-dessous une capture écran du rapport consolidé, du
rapport agrégé et les dernières lignes du tableau de résultats :
http://christophe.mayani.free.fr/jmeter/rapports.jpg
Cela veut dire que si il y a 50 utilisateurs simultanées sur le
serveur, un internaute risque de recevoir sa page en 21 secondes ??
Bon il faut quand même préciser que le site en question est un site de
e-commerce qui tourne sous magento (assez gourmand niveau ressources).
Quand le test de charge est en cours je vais sur le site avec mon
navigateur et je constate avec firebug que la page met environ 10-12
secondes pour se charger (c'est le temps que je constate dans le
tableau de résultats).
Concernant le récepteur graphique que tu m'as conseillé, j'utilise
jmeter-plugins que l'on peut récupérer sur google code (tu dois
connaitre je présume), voici quelques copies des résultats:
Distribution des temps de réponse :
http://christophe.mayani.free.fr/jmeter/responses_times_distribution.jpg
Temps de réponse sur le temps : http://christophe.mayani.free.fr/jmeter/responses_times_over_time.jpg
Temps de réponse percentile : http://christophe.mayani.free.fr/jmeter/responses_times_percentiles.jpg
Temps de réponse sur les threads : http://christophe.mayani.free.fr/jmeter/responses_times_threads.jpg
Penses-tu que ces temps sont vraiment représentatifs ?
Sont-ils inquiétants ?
Concernant les logs dans Apache, j'ai modifié le format pour afficher
le temps des réponses (microsecondes et secondes). En revanche, ça ne
correspond pas avec les temps de Jmeter.
Par exemple j'envoie une seule requête sur le site : Apache > 1647193
microsecondes donc 1647,19 millisecondes - Jmeter > 1879
millisecondes), et la différence se creuse avec des requêtes
concurrentes.
Je pense que le temps affiché dans les logs Apache correspond au temps
de traitement de la requête. Le temps de réponse affiché par Jmeter
correspond au temps de traitement du serveur + temps de retour (à mon
avis).
D'ailleurs est-il possible d'afficher la date/heure de fin d'une
requête (sans avoir à faire le calcul Date de fin = date de début +
temps de réponse ) ?
Merci par avance pour ton aide !
chris
web pour de déduire quel est le plus performant.
Quels tests me conseilles-tu de faire avec Jmeter pour obtenir des
résultats représentatifs ?
Merci
Milamber
Le 06/03/2011 01:35, chris a ecrit :
> Bonjour,
>
> Tout d'abord merci beaucoup pour ta rapidité et ton efficacité dans
> ta réponse :)
>
> J'ai fait de nouveaux tests de charge mais cette fois-ci sur un
> autre serveur et un autre site, serveur sur lequel j'ai l'accès root
> (c'est mieux, hein :p ?)
> Je n'ai pas les accès à la plateforme citée ci-dessus, c'était juste
> pour faire un essai.
>
> Sur mon serveur, je constate en faisant le même test de charge (50
> VU pendant 60 secondes) des temps de réponse plutôt longs également
> (pas aussi longs que mon exemple d'hier mais pas négligeables pour
> autant). En effet, je constate un temps de réponse max de plus de 21
> secondes durant le test, ci-dessous une capture écran du rapport
> consolidé, du rapport agrégé et les dernières lignes du tableau de
> résultats :
>
> http://christophe.mayani.free.fr/jmeter/rapports.jpg
>
> Cela veut dire que si il y a 50 utilisateurs simultanées sur le
> serveur, un internaute risque de recevoir sa page en 21 secondes ??
> Bon il faut quand même préciser que le site en question est un site
> de e-commerce qui tourne sous magento (assez gourmand niveau
> ressources).
> Quand le test de charge est en cours je vais sur le site avec mon
> navigateur et je constate avec firebug que la page met environ 10-12
> secondes pour se charger (c'est le temps que je constate dans le
> tableau de résultats).
Firebug utilise le moteur réseau de firefox, qui fait des flux parallèles pour charger une page et ses ressources liées (images, etc)
JMeter ne fait pas de flux parallèle pour télécharges les ressources liées, mais 1 flux en série
(dans ton test, ta requête est une seule page html sans les ressources liées ou avec (la case à cocher dans l'élément requête http) ?)
>
> Concernant le récepteur graphique que tu m'as conseillé, j'utilise
> jmeter-plugins que l'on peut récupérer sur google code (tu dois
> connaitre je présume), voici quelques copies des résultats:
>
> Distribution des temps de réponse :
> http://christophe.mayani.free.fr/jmeter/responses_times_distribution.jpg
>
>
>
>
Temps de réponse sur le temps : http://christophe.mayani.free.fr/jmeter/responses_times_over_time.jpg
> Temps de réponse percentile :
> http://christophe.mayani.free.fr/jmeter/responses_times_percentiles.jpg
>
>
>
>
Temps de réponse sur les threads : http://christophe.mayani.free.fr/jmeter/responses_times_threads.jpg
>
> Penses-tu que ces temps sont vraiment représentatifs ?
Oui les graphiques représentent bien tes résultats
Non, car peut-être que ton scénario de test n'est pas très représentatifs de la réalité d'utilisation de ton site : test qui dure environ 1 min 9 sec, 50 users avec une seule et même requête, période de montée en charge trop courte.
> Sont-ils inquiétants ?
Non, le 90e centile (13,9s) est proche du temps de réponses moyen (10s). Et les graphiques montrent sous différents angles que la valeur max est ponctuelle.
Bien qu'il semblerait que ton serveur voit ses temps de réponses se dégrader avec la montée du nombre VU simultanés.
Ce est qui normal si ton serveur n'est pas assez costaud ou bien qu'il y a un problème de ressources quelques part. Pour répondre, il faut 1/ voir les métriques systèmes sur ton serveur, 2/ voir les métriques systèmes sur ta machine JMeter (surtout car je pense que tu exécutes ton tir de charge en mode graphique, ce qui n'est pas recommandé)
>
> Concernant les logs dans Apache, j'ai modifié le format pour
> afficher le temps des réponses (microsecondes et secondes). En
> revanche, ça ne correspond pas avec les temps de Jmeter. Par exemple
> j'envoie une seule requête sur le site : Apache > 1647193
> microsecondes donc 1647,19 millisecondes - Jmeter > 1879
> millisecondes), et la différence se creuse avec des requêtes
> concurrentes. Je pense que le temps affiché dans les logs Apache
> correspond au temps de traitement de la requête. Le temps de réponse
> affiché par Jmeter correspond au temps de traitement du serveur +
> temps de retour (à mon avis).
Si la différence se creuse, peut être est-ce un problème de performance de ta machine JMeter (voir ci-dessus)... ou bien un problème saturation réseau...
> D'ailleurs est-il possible d'afficher la date/heure de fin d'une
> requête (sans avoir à faire le calcul Date de fin = date de début +
> temps de réponse ) ?
# Save the start time stamp instead of the end
# This also affects the timestamp stored in result files
sampleresult.timestamp.start=true
Il faut mettre false.
A+
Milamber
Milamber
Le 06/03/2011 02:00, chris a ecrit :
> J'ai oublié de dire que je fais ces tests afin de comparer 2 serveurs
> web pour de déduire quel est le plus performant.
>
Cela veut dire que les deux serveurs n'ont pas le même paramétrage ? le
même type de serveur web ? la même puissance ?
Ou bien ce sont les mêmes mais vous ne voyez pas la différence ?
> Quels tests me conseilles-tu de faire avec Jmeter pour obtenir des
> résultats représentatifs ?
>
Déjà, faire un scénario de test plus représentatif d'une utilisation réelle.
Et plus long (genre 1h)
Exécuter le même test sur les deux serveurs dans les mêmes conditions
(en particulier le même contenu de base de données, le même paramétrage
(si nécessaire), etc)
(bien sur faire le test en mode non graphique (voir mon blog))
Puis comparer les résultats.
A+
Milamber
> Merci
>
>
chris
Une fois de plus merci pour ta réponse très rapide et très précise.
Pour être plus précis, je dois comparer les performances de 2
plateformes afin de m’orienter sur l’une ou sur l’autre pour
l’hébergement d’un site de e-commmere sous Magento.
La plateforme A : Load Balancer + 2 serveurs web frontaux + 1 SGBD
Pour les 3 serveurs :
Processeur Intel 5550 Bi Quad Core à 2.6Ghz
RAM 8 Go DD3
Disques SAS 2x80 Go 15'000 T/min
Bande passante 100 Mbs Full duplex (sur le datacenter)
Plateforme B : 1 seul serveur dédié
Xeon 3440 Quad Core HT à 2.53Ghz
RAM 8 Go DDR3
Disque SATA 2x500 Go
Bande passante 100 Mbs Full duplex (sur le datacenter)
Je sais bien que c’est incomparable mais nous avons besoin de
statistiques concrètes afin d’en déduire si la différence de
performance entre les 2 plateforme justifie la différence de prix car
la plateforme A est beaucoup plus chère que la plateforme B.
Les 2 plateformes sont sous Linux Debian et utilisent Apache 2.2 et
MySQL 5.
Durant mes tests, le site sur A est identique au site sur B au niveau
du code et des données en base.
Je fais toujours le même test de charge pour l’instant (50 VU durant
60 secondes). Au final, et comme tu me l'as conseillé, je ferai des
tests plus représentatifs (environ 1heure). Sur la plateforme B (celle
ou j’ai l’accès root) voici les copies d’écran de htop et ifstat
durant le tir pour avoir une idée de la charge CPU/RAM/NET :
http://christophe.mayani.free.fr/jmeter/htop.jpg
http://christophe.mayani.free.fr/jmeter/ifstat.jpg
On constate très clairement que le serveur est à genoux durant le tir
(les 8 threads du CPU sont à 100% !).
J’ai exécuté ces tests en mode non-graphique car en effet lors de mes
tirs j’avais plusieurs récepteurs pour générer tous les graphiques
possibles (jmeter-plugins) ! Malgré tout, les résultats se rapprochent
du tir en mode graphique (voir post précédent), les voici :
http://christophe.mayani.free.fr/jmeter/jmeter-non-gui.jpg
Faut-il ensuite traiter le fichier de logs CSV si on veut des beaux
graphiques ou est-il possible de réimporter les résultats dans Jmeter
en mode GUI pour les examiner ?
En ce qui concerne ma requête durant mon tir, c’est une seule page
HTML sans les ressources liées. Firebug affiche en effet le temps de
chargement global (en comptant les temps de récupération des
ressources liées) mais on peut voir aussi le détail de chaque requête,
voir ici :
http://christophe.mayani.free.fr/jmeter/firebug.jpg
Par ailleurs, sur un autre serveur web, j’ai tapé la commande «
netstat –atn | grep –i established | wc –l » pour voir le nombre de
connexions ouvertes et j’ai eu en retour 54. Mais ça ne correspond pas
à 54 utilisateurs en train de traviailler en même temps, il peut y
avoir des délais entre 2 requêtes (sachant que par défaut le KeepAlive
de Apache est à 15 secondes), n'est-ce pas ?
Donc le test de charge avec 50 VU est un test plutôt lourd qui simule
des demandes au même moment (et en boucle), comme si 50 internautes
cliquaient en même temps sur le bouton de la souris pour demander une
page !! Ce qui est assez rare pour des petits/moyens sites. Qu’en
penses-tu ?
Enfin, dans les statistiques, je ne comprends pas très bien à quoi
correspond exactement le 90e centile et en quoi cette donnée est-elle
si importante.
Voilà j'espère que j'ai été clair et encore une fois merci par avance
pour ton aide.
Christophe.
Milamber
Ci-dessous,
Le 07/03/2011 23:32, chris a ecrit :
> Bonjour Milamber,
>
> Une fois de plus merci pour ta réponse très rapide et très précise.
>
Avec plaisir.
> Pour être plus précis, je dois comparer les performances de 2
> plateformes afin de m’orienter sur l’une ou sur l’autre pour
> l’hébergement d’un site de e-commmere sous Magento.
>
Ok. Quelle est la charge que doit supporter le site (en termes de pages
vues par jour ou heure) ?
> [snip]
>
> Je fais toujours le même test de charge pour l’instant (50 VU durant
> 60 secondes). Au final, et comme tu me l'as conseillé, je ferai des
> tests plus représentatifs (environ 1heure). Sur la plateforme B (celle
>
Oui ce sera mieux, car le scénario de test que tu fais ne vas pas
vraiment t'aider à faire un choix.
Il faut au minimum, faire une montée en charge de 50 sec (ce qui fera 1
nouveau VU par seconde, et le faire durer 50+60=110 sec)
(mais bon le tir sur 1h avec un vrai scénario de visite sera le mieux)
> ou j’ai l’accès root) voici les copies d’écran de htop et ifstat
> durant le tir pour avoir une idée de la charge CPU/RAM/NET :
>
> http://christophe.mayani.free.fr/jmeter/htop.jpg
> http://christophe.mayani.free.fr/jmeter/ifstat.jpg
>
> On constate très clairement que le serveur est à genoux durant le tir
> (les 8 threads du CPU sont à 100% !).
>
On comprend mieux les temps de réponses qui se dégradent dans tes tirs.
Visiblement 50 VU c'est trop.
> J’ai exécuté ces tests en mode non-graphique car en effet lors de mes
> tirs j’avais plusieurs récepteurs pour générer tous les graphiques
> possibles (jmeter-plugins) ! Malgré tout, les résultats se rapprochent
> du tir en mode graphique (voir post précédent), les voici :
>
> http://christophe.mayani.free.fr/jmeter/jmeter-non-gui.jpg
>
> Faut-il ensuite traiter le fichier de logs CSV si on veut des beaux
> graphiques ou est-il possible de réimporter les résultats dans Jmeter
> en mode GUI pour les examiner ?
>
Oui, il faut une analyse à froid. Pour cela il faut démarrer un Jmeter
vide, puis lui ajouter un ou plusieurs récepteurs, dans chaque
récepteur, dans le champ "ecrire dans un fichier" tu cliques sur le
Parcourir, puis tu sélectionnes le "report/test1.csv".
> En ce qui concerne ma requête durant mon tir, c’est une seule page
> HTML sans les ressources liées. Firebug affiche en effet le temps de
> chargement global (en comptant les temps de récupération des
> ressources liées) mais on peut voir aussi le détail de chaque requête,
> voir ici :
>
> http://christophe.mayani.free.fr/jmeter/firebug.jpg
>
14 sec pour 1 seule requête, c'est beaucoup (d'autant qu'avec Firebug,
tu ne fais pas un test de charge).
Pas la peine d'utiliser JMeter à ce niveau, tu as un problème de perf
sur cette requête. Si je dois aller sur un site de e-comm avec 14 sec
pour une requête, je vais le quitter vite fait ;-)
> Par ailleurs, sur un autre serveur web, j’ai tapé la commande «
> netstat –atn | grep –i established | wc –l » pour voir le nombre de
> connexions ouvertes et j’ai eu en retour 54. Mais ça ne correspond pas
> à 54 utilisateurs en train de traviailler en même temps, il peut y
> avoir des délais entre 2 requêtes (sachant que par défaut le KeepAlive
> de Apache est à 15 secondes), n'est-ce pas ?
>
Comprends pas la question... c'est qui cet autre serveur ?
> Donc le test de charge avec 50 VU est un test plutôt lourd qui simule
> des demandes au même moment (et en boucle), comme si 50 internautes
> cliquaient en même temps sur le bouton de la souris pour demander une
> page !! Ce qui est assez rare pour des petits/moyens sites. Qu’en
> penses-tu ?
>
Effectivement, là tu fais du 50 "vrai" simultanés sur la *même* requête
et sans temps de pause entre deux itérations d'un même VU... C'est clair
que c'est des furieux.
D'après mon point de vue cela doit représenter dans les 3000
utilisateurs "réels" qui appellent ta page en boucle (avec des temps de
pause)
Est-ce que c'est la charge que devrait supporter ton site ? si oui, il
faut revoir ton architecture et/ou ajouter des composants de perf (genre
server de cache,etc)
> Enfin, dans les statistiques, je ne comprends pas très bien à quoi
> correspond exactement le 90e centile et en quoi cette donnée est-elle
> si importante.
>
Le 90e centile, c'est voir Wikipédia ;-) mais en anglais "90 percentile"
Grossomodo, le 90e centile : on trie par ordre croissant les temps de
réponse, puis on regarde le temps de réponse de l'échantillon situé à
90% (dont pour 1000 requêtes triées par ordre croissant de temps de
réponse, on prend le temps du 900eme échantillon)
Cela permet d'éliminer les "imperfections" dans les résultats d'un tir.
Il arrive parfois que les objectifs soit plus nuancés que "je veux que
100% des requêtes soit à moins de 2 secondes", et que l'on est comme
objectif "90% des réponses à moins de 2 sec")
Toujours est-il qu'il est logique de penser que si la valeur du 90e
centile est proche de la moyenne et que le 90e centile est proche du
max, alors on a certainnement des temps de réponse uniformes (la mer est
calme, lisse comme de l'huile)
Si le 90e centile est haut par rapport à la moyenne, tout en restant
relativement faible par rapport au max, on est plutôt en mer agitée....
A mon avis, il faut vraiment que tu fasses un scénario plus varié qu'une
seule requête, avec une montée en charge plus douce et une plus grande
durée, tout en supervisant ta plateforme. Car là cela me semble
difficile de faire un choix de perf de plateforme sur 60 secs.
A+
Milamber
chris
Le site doit supporter 20'000 pages vues et 1500 visites par jours
avec des pics
à 30'000 pages vues et 2500 visites.
Par contre attention, dans firefug le temps de 14 secondes pour le
chargement de la page c'est durant le test de charge (50 VU
simultanés), en temps normal le temps de chargement est de 1s à 2s
(heureusement sinon je serais en dépression :))
L'autre serveur sur lequel j'ai fait le netstat, c'est un serveur qui
n'a rien à voir avec les 2 plateformes. C'est un serveur web de prod
que j'administre et qui héberge le même type de site (magento). Sur
celui-ci j'ai donc fait un "nestat -ant | grep -i established | wc -l
" pour avoir le nombre de connexions ouvertes et j'ai eu 54 a un
instant t. Mais à ce moment là, les temps de chargement sur le site
via le navigateur sont excellents. Je disais donc que les 54
connexions ouvertes ne correspondent nullement aux 50 VU en train de
bousculer le serveur durant un tir Jmeter, les 50 VU demandant en
boucle et en même temps les pages web (t'as raison c'est des furieux
^^).
En ce qui concerne le 90e centile,merci pour ton explication très
claire. J'avais bien regardé l'explication sur wikipedia :), mais je
ne comprenais pas pourquoi cette donnée était importante dans les
résultats d'un test de charge et pourquoi le 90e et non pas le 85e ou
le 95e.
Je vais commencer à faire un test de charge plus représentatif tel que
tu me l'as conseillé : montée en charge progressive avec requêtes sur
plusieurs pages et avec une durée plus longues ! Durant ce test, dois-
je récupérer les ressources liées aux pages ou bien ce n'est pas
nécessaire étant donné qu'elles seront mises en caches dès la 1ère
requête ?
Merci à toi pour ton aide, j'y vois beaucoup plus clair depuis le
début de notre discussion !
A+
chris
je comprends bien ?
Parce que sinon il faut s'appeler Google ou Facebook pour que le
serveur soit à l'aise durant un test de charge de 50-100 VU en train
de demander constamment la même page sans pause, non ?
chris
On 8 mar, 19:09, chris <christophe.may...@gmail.com> wrote:
> Dans mon test, tu peux conseilles aussi de faire des temps de pause si
> je comprends bien ?
>
comprends bien ?
Milamber
Ci-dessous,
Le 08/03/2011 09:58, chris a ecrit :
> Bonjour Milamber,
>
> Le site doit supporter 20'000 pages vues et 1500 visites par jours
> avec des pics
> à 30'000 pages vues et 2500 visites.
>
Ce sont des petits chiffres, bien en dessous de tes 50 VU simultanés.
Si tu prends les pics, en comptant une journée de 10 h "d'ouverture" (de
10h à 20h, les gens dorment la nuit), cela du 3000 pages vues par heure,
soit 50 pages par minutes, soit moins de 1 chaque seconde...
Pour simplifier, tu peux faire du 1 page par seconde (c'est-à-dire un VU
qui demande 1 page à chaque seconde)
Accessoirement avec 30000 p/v et 2500 visites, moi je vois 12 pages vues
par visite. Ce qui veut dire qu'un VU (le même) doit visiter 12 pages
différentes lors d'une itération (et non pas 12 VU qui visitent 1 page)
> Par contre attention, dans firefug le temps de 14 secondes pour le
> chargement de la page c'est durant le test de charge (50 VU
> simultanés), en temps normal le temps de chargement est de 1s à 2s
> (heureusement sinon je serais en dépression :))
>
ok
[snip]
> Je vais commencer à faire un test de charge plus représentatif tel que
> tu me l'as conseillé : montée en charge progressive avec requêtes sur
> plusieurs pages et avec une durée plus longues ! Durant ce test, dois-
> je récupérer les ressources liées aux pages ou bien ce n'est pas
> nécessaire étant donné qu'elles seront mises en caches dès la 1ère
> requête ?
>
Tu peux les laisser, tu ajoutes un gestionnaire de cache dans la racine
de ton arbre jmeter, et tu le vides à chaque itération (après les 12
pages d'un VU)
JMeter sait gérer les codes 304 (déja dans le cache), et tu fais "de la
vrai" simulation.
Par contre si il y a des ressources externes (genre google adword, pub,
analytics), il faut bien entendu les supprimer (car google et co. va te
bannir si tu insistes un peu trop à tirer sur ses sites)
A+
Milamber
Milamber
Oui il est impératif de faire des temps de pauses, surtout afin de
coller à la charge à simuler (1 VU fait du 12 pages par itération, il
faut 60 pages par minute au total (tous VU confondus) sur ton serveur
(i.e. sur les logs d'accès Apache, tu dois voir seulement 60 requêtes
(hors ressources) pour chaque minute, c'est tout.
Tu peux lire ce billet au sujet des temps de pause si jamais :
http://blog.milamberspace.net/index.php/2009/02/08/jmeter-think-time-et-ordre-dexecution-les-bons-plans-212.html
A+
Milamber
Le 08/03/2011 19:01, chris a ecrit :
chris
Bonjour Milamber,
> Accessoirement avec 30000 p/v et 2500 visites, moi je vois 12 pages vues
> par visite. Ce qui veut dire qu'un VU (le même) doit visiter 12 pages
> différentes lors d'une itération (et non pas 12 VU qui visitent 1 page)
bien 3 VU qui en visitent 3 ?
Une dernière chose, en plus de faire ce test de charge qui consiste à
simuler les conditions réelles, je dois également faire un test de
saturation qui doit me permettre de savoir ce que le serveur peut
encaisser au maximum (connexions simultanées max, visites max, pages
vues max, etc ...). Cela me permettra de connaitre le seuil à ne pas
dépasser et donc de rester vigilant sur les stats car le site prend
doucement de l'ampleur. D'après toi, quel test puis-je mettre en place
afin d'avoir des résultats concrets ?
Merci.
chris
30000 p/v et 2500 visites par jour cela représente une moyenne de 12
pages vues par visite (au temps pour moi ^^).
Je pense qu'il faut également prendre dans le calcul de nombre de
visites par jour afin de déterminer quel sera le test de charge à
mettre en place pour une simulation qui reflète la réalité.
Si je prends comme exemple :
*50'000 pv et 7000 visites par jours*
Cela représente donc 50'000 / 7000 = 7,14 pages vues par visites
Sur une période de 10h :
5'000 pv / heure
83,33 pv / min
1,38 pv /sec
mais aussi :
700 visites / heure -> 11 visites / min
On aurait donc environ 83 pv et 11 visites par minute !
Maintenant dans Jmeter je fais le tir suivant : 11 VU qui demandent 7
pages pour chaque itération pendant 60 secondes
Dans le tableau de résultats je vérifie le nombre de requêtes totales
et j'en déduis le délai d'attente qu'il faudra que j'ajoute pour bien
avoir mes 83 pages / minute.
Que penses-tu de ce calcul ? Ce test sera proche de la réalité ?
Merci.
A+
chris
Milamber
Tes calculs sont bons.
Il faut compléter par :
La montée en charge :
60 sec / 11,67 VU = 5,14 sec
Ces 5 secs seront l'intervalle entre chaque VU lors de la période de
Ramp-up (montée en charge). Le champ Ramp-up sera donc : 60 sec et le
champ VU : 11
Le temps de pause entre chaque requête d'un même VU lors d'une
itération de 7 pages
60 sec / 7,14 pv = 8,4 sec
ces 8,4 sec sont le temps de pause entre chaque requête donc (par
exemple avec un échantillon "Action test" avec la pause à 8400 ms)
Au bien (c'est mieux), tu peux utiliser un Compteur de débit constant
à avec 7,14 éch par minute pour l'unité courante.
A+
Milamber
Milamber
Ci-dessous,
fonction de tes injecteurs) , ex 1000 VU
Ne pas mettre de temps de pause (faire des furieux)
Avoir des assertions à toutes les étapes clés du scénario (pour
détecter immédiatement quand le serveur est en rupture)
Mettre un période de montée en charge qui correspond à la durée du tir
(ex 3600 sec : 1h)
Ce qui fera une nouvelle VU chaque 3,6 minute
Avoir un récepteur configurer pour ne capter que les erreurs dans un
log (csv ou jtl).
Lancer son tir (mode non-gui), tout en surveillant le fichier de logs
des erreurs (d'assertion).
A+
Milamber
>
> Merci.
chris
Je vais mettre tout ça en pratique !
A+