Mes threads se bloc plus avec la jvm 6 qu'avec la jvm 5u22

Version imprimable

12/05/2010, 15h00
Sfaxiano

Mes threads se bloc plus avec la jvm 6 qu'avec la jvm 5u22

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
19/05/2010, 12h01
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
19/05/2010, 12h28
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.
19/05/2010, 12h41
Sfaxiano

Citation:

Envoyé par tchize_

comme on a pas ton code,

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

Citation:

Envoyé par tchize_

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.

Citation:

Envoyé par tchize_

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)

Citation:

Envoyé par tchize_

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.
19/05/2010, 13h48
tchize_

Citation:

Envoyé par Sfaxiano

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.

Citation:

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.
19/05/2010, 15h11
Sfaxiano

Citation:

Envoyé par tchize_

-> 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)
19/05/2010, 15h17
Sfaxiano

ça serais pas liée au serveur d'application que j'utilise

je travail avec jboss 4.2, la gestion des connexions est meilleur pour ce serveur avec la jvm 5u22 par rapport à la jvm 6u18, non??
19/05/2010, 15h17
tchize_

quelle taille font les connections pool? Pour avoir garantie de non blocage du thread la tailel du connection pool doit être de TxN où T est le nombre de thread HTTP de ton serveur et N est le nombre maximum de connections simultanées dont va avoir besoin ta connection.

ainsi imaginons un portail qui aie besoin d'un connection pour hibernate, une pour l'authentification et parfois une troisième pour le framework machin. Avec 200 threads HTTP (si ma mémoire est bonne c'est le défaut sur jboss), Ton connection pool devrai avoir une taille max de 600 connections. (Et une taille min de 401 pour éviter les deadlock ;) )

Utilise-tu des bloc synchronized sur ton code?
Y a-t-il des cache partagé par les thread (par exemple un cache de second niveau hibernate)?
Utilise-tu d'autres ressources partagées en quantité limitées?
Le garbage collector interviens-til?

Tous ces points sont des cause de suspension de thread, le comportement variera d'un jvm, d'un os et d'un hardware à l'autre.

C'est certainement pas le serveur (jboss) qui ralentit. Le traitement du serveur fait à peine quelques millisecondes par requete, et t'en est à 1s par action -> le cout du serveur est marginal.

Citation:

Envoyé par tchize_

quelle taille font les connections pool? Pour avoir garantie de non blocage du thread la tailel du connection pool doit être de TxN où T est le nombre de thread HTTP de ton serveur et N est le nombre maximum de connections simultanées dont va avoir besoin ta connection.

j'ai ça dans le fichier server.xml
Code:

1 2 3 4 5 6 <Connector port="8080" address="${jboss.bind.address}" maxThreads="250" maxHttpHeaderSize="8192" emptySessionPath="true" protocol="HTTP/1.1" enableLookups="false" redirectPort="8443" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" URIEncoding="UTF-8" />
j'ai 100 threads utilisateur qui fonctionne en prallel, je crois que les parametres sont suffisant.

Citation:

Envoyé par tchize_

Utilise-tu des bloc synchronized sur ton code?

oui j'utilise beaucoups de synchronisation (mais je crois que la jvm 6 apporte plusieurs améliorations à ce niveau).

Citation:

Envoyé par tchize_

Y a-t-il des cache partagé par les thread (par exemple un cache de second niveau hibernate)?

je sais pas je dois voir comment liferay gère les connexions base de donnée ( mais dans les piles d'appèl des threads je trouve des appels hibernate)

Citation:

Envoyé par tchize_

Le garbage collector interviens-til?

j'utilise le meme collector dans les deux tests (ParallelOldGC avec 2 threads GC)

Citation:

Envoyé par tchize_

C'est certainement pas le serveur (jboss) qui ralentit. Le traitement du serveur fait à peine quelques millisecondes par requete, et t'en est à 1s par action -> le cout du serveur est marginal.

mon problème c'est plus taux le nombre d'actions faite par l'utilisateur, est ce que le serveur n'intervient pas à ce niveau.

merci d'avance

19/05/2010, 16h30
tchize_

Citation:

Envoyé par Sfaxiano

oui j'utilise beaucoups de synchronisation (mais je crois que la jvm 6 apporte plusieurs améliorations à ce niveau).

oui et non, il me semble aussi qu'elle corrige quelques problèmes avec des synchro qui ne se faisaient pas ;)

Sinon, je parle du connection pool de la base de donnée (quelque part dans tes datasource), par du nombre de thread. En l'occurence, il te faudra, si on suppose que liferay n'utilise qu'une seule connexion, 250 connexion dans le pool de la DB pour éviter les chutes de perfs. Il faut voir aussi, vu la quantité de synchro que tu dit avoir, si il ne serait pas judicieux de descendre jboss à 50 threads http max, plutot que 250 pour limiter cette surcharge. Mais encore une fois, si t'es pas sur un serveur équivalent à la prod, tous les tweak que t'es occupé de faire, tu pourra les refaire différement sur le serveur de prod....
19/05/2010, 22h43
Sfaxiano

juste remarque:

le but de ces tests n'est pas l'application elle meme mais un comparatif entre la jvm 5u22 et la jvm 6,

c'est pour ça je cherche une explication sur le blocage inattendu avec la jvm 6