serveur crache

[Mugiwara]

salut, je suis de retour avec une nouvelle question :D.
Bon, à l'aide de Jmeter je veux stresser mon serveur avec plusieurs
injecteur jusqu'à ce qu'il crache.
La question est: comment savoir que le serveur a craché ?
est ce que le faite d'avoir un 100% de taux d'erreur indique que le
serveur a craché ou ce n'est pas suffisant. Je pose cette question car
avec dans un test par palier, quand j'atteins le max du nombre d'UV je
remarque un 100% de taux d'erreur, puis dés que ça redescend vers un
nombre d'UV inférieur le taux d'erreur diminue cela prouve que le
serveur marche encore.
Merci d'avance

[Milamber]

Bonjour,

Ci-dessous,

Le 10/08/2009 19:11, Mugiwara a ecrit :

> salut, je suis de retour avec une nouvelle question :D.
>

Pas de problème ;-)

> Bon, à l'aide de Jmeter je veux stresser mon serveur avec plusieurs
> injecteur jusqu'à ce qu'il crache.
>

Donc un test de robustesse.

> La question est: comment savoir que le serveur a craché ?
> est ce que le faite d'avoir un 100% de taux d'erreur indique que le
> serveur a craché ou ce n'est pas suffisant. Je pose cette question car
>

Un nombre d'erreur important ou au maximum ne signifie pas forcément que
ton serveur s'en planté.
Bien entendu, cela signifie qu'il y a un problème, mais son origine peut
être diverse : CPU indispo, réseau saturé, Firewall qui coupe la
communication car trop de trafic pour 1 même source, ton injecteur
saturé, le logiciel serveur d'applications qui plante, etc.

> avec dans un test par palier, quand j'atteins le max du nombre d'UV je
> remarque un 100% de taux d'erreur, puis dés que ça redescend vers un
> nombre d'UV inférieur le taux d'erreur diminue cela prouve que le
> serveur marche encore.
>

Il est possible que ton serveur arrête (ou refuse) les nouvelles
connexions après dépassement d'un certain nombre de client (par exemple
avec Apache, il y a la directive MaxClients, ou sur un Tomcat, le
maximum de threads concurrents (par défaut je crois que c'est 75) (Jboss
c'est 40 !) Dans ces cas, le serveur répond pour les 75 premiers puis
les autres sont en erreurs...

Pour définir un serveur planté, je préfère que c'est un serveur qui suit
à un test de charges (ou une action quelconque), ne répond plus aux
requêtes. Il est nécessaire de le redémarrer pour qu'il puisse à nouveau
fonctionner.

Pour un serveur qui temporairement ne réponds plus durant un test, mais
redevient disponible avec la baisse du nombre VU ou en fin de test, je
préfère parler de "serveur saturé ou surchargé". Il faut ensuite en
chercher la cause.


Une dernière chose sur la notion "d'erreurs" dans un test, il y en a de
plusieurs types : les erreurs de code HTTP (erreur 500 en particulier),
les erreurs suite à des assertions non vérifiées, les erreurs car
"aucune réponse" (timeout), etc. En fonction du type d'erreurs on peut
avoir des pistes pour localiser l'origine du problème.
On notera qu'une erreur 'assez fréquente' est de se tromper sur son
scénario et/ou la charge simulée par JMeter. Quand on débute (avec
JMeter), on peut faire un scénario et le configurer selon sa
compréhension de l'outil JMeter en pensant à par exemple "500
transactions par minute", mais dans la réalité, le positionnement d'un
compteur, contrôleur de débit, nombre de VU, etc... peut facilement
faire du 50000 transactions par minute (ou 500 par *secondes*), qui va
provoque une belle pagaille...
Il est donc important de bien vérifier (et contre-vérifier) son scénario
pour s'assurer de la charge simulée. Un moyen relativement simple est de
faire les statistiques d'utilisation du serveur Apache / IIS à partir
des logs "access_log" sur le serveur. Le nombre de requêtes/transactions
calculés doit être du même ordre que la cible.

A+
Milamber

> Merci d'avance
> >
>
>

[Mugiwara]

Je vous remercie énormément, c'est plus claire pour moi à présent.
J'ai utilisé un test par palier (3 palier) de 1150 UV et 5 injecteurs,
en tout ça donne 17250 UV et je crois ce n'est pas suffisant pour
craché JBoss