Discussion :

[Sfaxiano]

Bonjour,


j'ai fait un test entre deux version de la jvm : jvm 6u18 et la jvm 5u22 avec la meme application et dans les meme condition

à la fin des tests je trouve que la jvm 5 arrive a exécuter plus d'itération (action sur l'application ) alors que les temps de réponse sont suppérieur à ceux obtenue avec la jvm 6 qui exécute moins d'intération.
voici les valeur obtenu pour un test d'une heure

jvm 5u22 : environ 7427 action avec un temps de réponse environ 1.7s l'action
jvm 6u18 : environ 6985 action avec un temps de réponse environ 1.1s

j'arrive pas a comprendre comment on peu exécuter plus avec des temps de réponse plus elevé.

j'ai calculer avec l'outils VisualVM le temps "Monitor" de mes threads (j'ai 100 threads qui exécute ces actions : je trouve :

jvm 5u22 : temps total passé dans le monitor est 945s(9.45s par threads)
jvm 6u18 : temps total passé dans le monitor est 2139s ( en moyen 21 s par thread)

commen on peu avoir un tels résultat? et pourkoi mais threads se bloc plus avec la jvm 6

merci d'avance

[Sfaxiano]

Bonjour,

j'ai fais un programme avec jmx qui fait un stack dump chaque fois qu'un de mes threads se bloc

j'ai comparer les résultats avec les deux versions de la jvm 5u22 et 6u18

j'ai trouvé que

mes threads avec la jvm 6 se bloc 129 fois (un test de 20min avec 100 utlisatteur) sur un objet de type : "org.apache.jasper.servlet.JspServletWrapper" alors que les threads avec la jvm 5u22 se bloc uniquement 28 fois

commen je peu interprété ce résultat

et que fais cet objet : "org.apache.jasper.servlet.JspServletWrapper"

merci

[tchize_]

comme on a pas ton code, on peut pas savoir comment tu gère tes Threads et t'expliquer la différence. 1s / action pour une application web, c'est beaucoup.

Pour le cas "plus d'action avec plus d'attente par action" c'est finalement tout a fait normal. Si j'exécute 500 opérations par minutes, par tranche de 100 opérations en // ou de 200 opération en // qui saturent le CPU dans les deux cas. Le temps total sera similaire, mais le temps passé dans chaque Threads pour le deuxième cas sera supérieur (deux fois plus élevé). Il ne faut donc pas confondre temps de réponse et nombre de requetes par minute dans un serveur. Si je met un seul thread à tomcat, son temps de réponse va être extrèmement bas, par contre le nombre de pages servies à la minute risque d'être médiocre.

[Sfaxiano]

comme on a pas ton code,

le code est un portail liferay sur lequel je fais un test de charge avec 100 utilisateurs virtuel

on peut pas savoir comment tu gère tes Threads et t'expliquer la différence.

les threads sont géré par jboss, j'ai fait une capture de script de l'ensemble de mes actions sur le portail, ce script est utilisé par le generateur de charge.
les temps de réponse sont retourné par ce generateur.

1s / action pour une application web, c'est beaucoup.

bon, c'est liée à la perfromance de la machine de test (c'est pas une machine de production)

Pour le cas "plus d'action avec plus d'attente par action" c'est finalement tout a fait normal. Si j'exécute 500 opérations par minutes, par tranche de 100 opérations en // ou de 200 opération en // qui saturent le CPU dans les deux cas. Le temps total sera similaire, mais le temps passé dans chaque Threads pour le deuxième cas sera supérieur (deux fois plus élevé). Il ne faut donc pas confondre temps de réponse et nombre de requetes par minute dans un serveur. Si je met un seul thread à tomcat, son temps de réponse va être extrèmement bas, par contre le nombre de pages servies à la minute risque d'être médiocre.

les deux test sont faite dans les meme condition, avec le meme transaction rate, je lance 100 utilisateurs qui se connecte au portail , loop sur un ensemble d'action, puis à la fin du test ( après une heure) ils se deconnecte.
la comparaison est combien d'itération dans le loop on fait

c toujours les 100 threads crée par jboss qui serve les 100 VU.

[tchize_]

bon, c'est liée à la perfromance de la machine de test (c'est pas une machine de production)

Faire des tests de perf sur une machine non liée à la production ne sert à rien, en gros, les résultats seront complètement différent, voir parfois inversés. Il faut une machine similaire pour tirer la moindre conclusion sur les tests.

les deux test sont faite dans les meme condition, ...

Je disais juste qu'il n'y a pas de lien entre le temps de réponse moyen et le nombre réponses données. De plus, des résultats moyen ne servent à rien, si on a pas la dispersion, la variance et la marge d'erreur.


Enfin,
-> org.apache.jasper.servlet.JspServletWrapper est une classe internet à tomcat.
-> faire un stackdump prend du temps, ce qui va influencer ta mesure
-> je suis pas toujours certains de comprendre ce que tu monitore avec tes "blocages"....

Il y a plein de choses qui peuvent mettre une page web en attente:
-> plus de sockets dispos
-> attente d'un connection du pool
-> synchronisation d'un cache interne au conteneur
-> ......

A toi de jouer, sur une machine calibrée comme la prod, le nombre de Thread HTTP, le nombre de connections dans le pool, etc pour optimiuser tes temps de réponse.

[Sfaxiano]

-> je suis pas toujours certains de comprendre ce que tu monitore avec tes "blocages"....
.

lorsque j'ai calculé le temps de blocage total de tous les threads qui serve les utilisateur (http-..........) j'ai trouvé que la différence est presque égale au temps necessaire pour faire les actions en plus.
donc je me suis dis que il faut voir ou mais threads sont bloqué et pourquoi la jvm 5u22 se bloque moins par rapport à la jvm 6 alors que c'est le meme test et dans les memes conditions

j'arrive pas à trouver une réponse (une semaine d'investigation)