[JMETER] Tester la charge de tomcat?

Salut,
je voudrais évaluer la montée en charge d'un serveur Tomcat.

J'arrive a tester mes temps de réponse mais je ne sais pas comment interpreter le résultat.

Lorsque je fais:
20 utilisateurs se connectant en 3 secondes, le tout répété 30 fois

Je me retrouve avec des temps de réponse montant jusqu'a 40sec.
Est ce que j'en demande trop pour tomcat?
Est ce que mon test n'est pas cohérant?
Quels valeurs mettre pour simuler une utilisation standard?

Je voudrais simplement tester si j'ai 20 utilisateurs sur mon serveur. Est ce qu'il est sur les genoux...
Quel temps de réponse maximum je peux espérer?
Merci d'avance

Bonjour,
Lors de la définition des KPI (Key Performance Indicators), le temps de réponse doit être relatif à d'autres facteurs tels que le CPU -nombre et taille, la mémoire ou le nombre de context-switchs ... Sans cette définition correcte et préalable, personne ne pourra être à même d'interpréter les valeurs retournées.

D'un autre côté, des références comme TCP-W et les formules d'almeira ou de Little doivent entrer en compte pour établir un think time cohérent.

Ludo

Ca va pas t'aider, mais je dirais: ca dépends.....

Ca dépends du nombre d'utilisateurs que tu juges utile: Si tu souhaites qu'il puisse être 20, lance ton test avec 20.

Le temps de réponse, ça dépends du service rendu. Exemple: Google doit répondre en 3-5s maxi, avec 50000 utilisateurs simultanés.
Je fais une appli qui génére des stats sur le recensement de la population, elle doit répondre en 10mins à 10 utilisateurs.

Ca dépends tout à fait du service que tu rends.

Si c'est un service internet normal, je pense qu'au dela de 3s de delai, je commence à me dire que c'est lent.....


Mais tout est relatif :lol:

D'aprés mes souvenirs, la référence TCP-W concernant les sites E-Commerces spécifie qu'au-delà de 40sec d'attentes, le nombre d'utilisateurs concurrents est divisé par deux sachant qu'il ne s'agit pas en réalité de concurrence au niveau thread mais au niveau connexion -donc des threads endormis pendant le think-time (d'où la formule d'Almeira).

En fait, il s'agit simplement de ne pas imaginer la présence de goulots d'étranglement là où il n'y en aura jamais en production. Si le temps de réponse augmente avec le nombre d'utilisateurs, tu te trouve certainement dans une configuration limite : Thread not safe, connections SQL ou TCP pour les plus courants (sauf si le CPU atteind 70% pour un mono-processeur = charge limite).

Ludo

Merci pour vos réponses.
Je vais préciser.
J'heberge des web applications sur un server Tomcat5 Linux (redhat8).

Mes WebApps sont internes. J'aurai rarement 50 utilisateurs.

si j'ai bien compris, je met 50 user avec une période a 0 et une loop de 5.

Je devrai avoir qq chose qui se rapproche de la réalité?
J'viens de tester avec ces valeurs. Je suis a 50sec de moyenne :(

ps: Ma requete de test fait juste un login a mon appli. (ca peut p't'etre préciser...) Si j'fais le test sur une simple page HTML. les temps de réponse sont excellent (3ms)!
ca viens peut etre de mes temps de connection BD?

ps2: Config server:
Xeon 3Go avec 1Go de RAM

En effet, le login est le cas de figure le plus complexe car l'acces DB, la génération des tickets, la mise en place du cache ... sont trés couteux. Cependant, le think-time moyen est de 7s en random 50%, ce qui va améliorer le temps de réponse, Qu'en est-il du CPU ?

j'ai fait un autre test sur une page qui affiche un tableau html.
(ce tableau est fait suite a un select).

Je monte a 30sec de moyenne.

ps: je n'ai pas la possibilité de voir la charge CPU du serveur Tomcat ni d'Oracle. J'vois avec les admins demain

Les tests doivent suivre un ramp-up (selon le nombre d'utilisateurs et le temps) afin d'établir un temps de réponse de référence, c'est ce dernier qui permettra d'établir les bottlenecks par la suite. Sans méthodologie, les résultats seront inutiles.

Ludo.

Merci.
Mais je ne suis pas un pro pourrais tu préciser comment monter un vrai plan de tests?

40 secondes pour afficher une page avec 20 utilisateurs, cela me paraît énorme avec la config hardware dont on parle. Il y a peut-être un problème un paramétrage tomcat (logs,threads simultanés, pool de connexions DB). Si un pool de connexion DB est utilisé, il faut qu'il soit suffisament large pour satisfaire tous les clients connectés, sinon les threads attendent longtemps après une connexion DB et les temps de réponse s'allonge énormément.

Justement Aldo, il n y a pas 20 utilisateurs mais 250 puisque le think-time est nul et le loop de 5s (inférieur au temps de réponse). La machine étant petite et analysant un login, il n y a rien de surprenant : reste à connaître l'ensemble des indicateurs.

Ozmose, le plan de tests doit répondre à tes besoins mais il m'est difficile de te répondre en quelques lignes (j'espère d'ailleurs trouver le temps d'exposer les bases de la méthodologie dans un futur article).

Ludo

Merci beaucoup pour votre aide.
Peut etre avez vous des articles, topics, infos pouvant m'aider a améliorer mes perfs et a réaliser des tests réalistes???

Je poursuit mes recherches et vous tient informé.
MERCI A TOUS

ps: niveau Pool DB j'ai mis maxIdle 0 / maxWait 5000 / maxActive 0.
si je n'utilise pas de pool les perf sont équivalentes... :(

Niveau server.xml je suis:
<Connector acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" port="8080" redirectPort="8443" maxSpareThreads="75" maxThreads="150" minSpareThreads="25">

Tu peux jeter un coup d'oeil sur la page de l'un des gourous des perfs : Scott Barber Homepage

Ludo