Performances J2EE
Le
Utilisateur1
Bonjour à tous (et à toutes aussi),
Je précise que je suis NUL en Java (je ne le connais pas) !!
Je cherche des idées dans le cadre de mon mémoire autour des performances
des applications J2EE.
Ne savant pas par quoi commencer et n'étant pas programmeur java j'ai pris
l'application petstore 1.2 (de SUN).
L'idée serait de la déployer sur un serveur d'applications (j'ai pris
websphere 4.0x, avec un jdk 1.3).
Ensuite à travers un injecteur de charge (comme loadrunner) simuler une
montée en charge (utilisateurs virrtuels).
Rien de magique :
. Les temps de réponse augmentent lorsque le nbr d'utilisateurs augmente
. Si on change de serveur d'application ou de serveur de BD ou
d'environnement les résultats changent
Bon tout ceci est bien mais il me manque des références car qu'est ce qu'on
entend par performances ?
On peut parler aussi de la comparaison polimique entre petstore et petshop
(.net) : mais c'est un sujet existant.
Est-ce que quelqu'un a une idée pour commencer une étude de performances ?
des références sur des sujets liées aux performpances ou plutôt
de quoi peuvent venir les mauvaises performances ?
Cdt,
Yhab
Je précise que je suis NUL en Java (je ne le connais pas) !!
Je cherche des idées dans le cadre de mon mémoire autour des performances
des applications J2EE.
Ne savant pas par quoi commencer et n'étant pas programmeur java j'ai pris
l'application petstore 1.2 (de SUN).
L'idée serait de la déployer sur un serveur d'applications (j'ai pris
websphere 4.0x, avec un jdk 1.3).
Ensuite à travers un injecteur de charge (comme loadrunner) simuler une
montée en charge (utilisateurs virrtuels).
Rien de magique :
. Les temps de réponse augmentent lorsque le nbr d'utilisateurs augmente
. Si on change de serveur d'application ou de serveur de BD ou
d'environnement les résultats changent
Bon tout ceci est bien mais il me manque des références car qu'est ce qu'on
entend par performances ?
On peut parler aussi de la comparaison polimique entre petstore et petshop
(.net) : mais c'est un sujet existant.
Est-ce que quelqu'un a une idée pour commencer une étude de performances ?
des références sur des sujets liées aux performpances ou plutôt
de quoi peuvent venir les mauvaises performances ?
Cdt,
Yhab
Poser une question
ca peut arriver :)
ton memoire part bien alors :)
racontes nous cela...
quelle bonne idee :)
bencher avec quelque chose de specialement mal adapte pour cela....
ah voila une bonne question....
dommage....
oula mais faut redevenir serieux...
alors performance cela ne veut rien dire...
a quel niveau ? sur quelle machine ?
dans quel contexte ?
sur quelle appli ?
performance a vide (donc sur une requete) ou en charge ?
j'ai une petite idee sur le sujet mais eyrolles va pas etre content si
j'en dis trop :)
heu, clairement il y a trop de choses a dire pour les dire par
mail....
jerome
--
Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003
http://www.eyrolles.com/php.informa...?ouv_ean1382212111941
match petshop (.net)/petstore (j2ee) dit le stp...
Tu as parlé d'Eyrolles (quel livre ?). D'accord avec toi que le sujet est
vaste mais disons que la référence machine
est un PC standard du marché, l'appli est petstore, le serveur
d'applications java est WAS 4.0x, une BD Oracle 9i,
injecteur de charge loadrunner.
Les perfs dépendent
- du CODE : J'ai trouvé qq articles dans le magasine JAVA (N°101) sur les
perfs. liées à la manière de coder
- de la JVM : ???
- du garbage collector ???
- du jdbc ?
- du paramétrage de la datasource (pool de connexion) ?
- de l'optimisation des requêtes en BD, et de la volumétrie
Si quelqu'un a une expérience la dessus ?
par mail ou en dehors du mail mais il faut que j'avance car je suis noyé
pour le moment et je ne sais pas par quel bout démarrer le Pb.
"jerome moliere" news:c0osfp$1a1t$
J'ai vu passé un livre au titre laconique "Java Performance" chez
O'reilly je crois. Rien à dire: il est complet sur la démarche de
benchmarking et amélioration de performance.
Le code a souvent peu d'importance sur les perfs sauf en cas de
grosses conneries. (copie de tableaux à n'en plus finir,
construction, destruction des gros objets pour pas grand chose...)
Oui, les perfs dépendent de la JVM. Si tu fais un bench avec la même
appli sur les JVM de Sun 1.2, 1.3, 1.4... il y a vraiment des
progrès. Mais souvent la JVM est imposée par la version du serveur
J2EE
Avec WAS 4.0, tu es skotché à la JVM d'IBM en version 1.3.1 -
impossible de faire de comparaison et elle pourrait ne pas être
flateuse... Si ton appli J2EE est portable - si si ce n'est pas une
évidence - tu peux comparer avec BEA WebLogic Service 8.1 et leur JVM
JRockit !
Dans une appli J2EE, la bête noire est le bloc 'synchronized'. Il
faut savoir que le principe d'un contenaire J2EE est le pooling des
composants et les travaux concurrents de plusieurs threads.
On peut dire aussi que si ton appli utilise du code natif qui n'est
pas thread-safe et ré-entrant, ta montée en charge ne sera pas
efficace.
Petite procédure de bench:
- créer des scénarios proches du réel sur la façon dont l'utilisateur
va utiliser le programme (j'aime bien Grinder pour faire cela) -
l'important dans un scénario comme celui-là est le "think time" -
temps de saisie de l'utilisateur entre deux appels ce qui permet au
serveur de soufler.
- commencer avec peu d'utilisateurs virtuels (de 1 à 10) et voire si
la montée en charge est linéaire - si elle ne l'est pas =>
synchronized ou verrous dans la base - inspecter le code !
- en général, une appli qui travaille beaucoup avec la base bloque de
ce côté, un bon admin Oracle activera le tracing et sera capable de
te dire quelles sont les requêtes trop lentes (si elles sont
exécutées par ton scénario bien sûr) et comment ajouter des index
et ré-écrire tes requêtes (ordre des where par exemple) pour gagner
beaucoup et très vite
On constate que la base soufre si elle est proche du 100 % de CPU
alors que le WAS ne consomme pas beaucoup de CPU.
- Avec WebSphere, il y a l'outil ResourceAnalyzer (ou Tivoli
Performance Viewer dans la v5.0) qui permet de suivre l'activité de
la JVM et des EJBs, Servlet pour voir quel composant est lent ou
pose problèmes:
- le nombre de threads dans les pool Servlet et ORB
- le nombre de Connection dans le pool des DataSource
- les attentes sur monitor: encore les synchornized !
- la mémoire et trop d'activité GC: code avec des objets "jetables"
à améliorer
- Ensuite on monte en charge... on utilise les scénarios pour grimper
progressivement à la charge voulue. Attention, on cherche toujours
le point critique entre les resources disponibles (CPU,
mémoire,...) et le nombre d'utilisateurs maximum estimé (avec
l'outil de montée en charge et les scénarios)
Si ton CPU est proche de 100 % lorsque tu passe de 20 utilisateurs
virtuels à 25, ta limite actuelle est alors de 20 utilisateurs - et
il faut trouver les réglages pour passer au-delà, éventuellement
changer de hardware !
Il faut savoir qu'un outil de montée en charge, même avec des
scénarios réalistes, provoque plus de charge que des vrais
utilisateurs qui travaillent...
- Comment dire que les perfs sont satisfaisantes ? En fait il faut
les définir avant de commencer: par exemple, on veut avoir 80
personnes en même temps, et avoir des réponses de moins de 3
secondes 90 % du temps. On peut aussi définir des limites plus
grandes pour certaines actions qui sont forcément plus longues
(sortie d'une liste importante de la base ou gros calcul) - exemple
7 secondes 80 % du temps pour cette requête
Très important:
- faire des mesures de charge avec l'état initial et aller jusqu'en
butée (100 % CPU) pour connaître la limite initiale
- activer les mesures dans la base et faire un premier tuning
- mesurer de nouveau
- activer les mesures dans le ResourceAnalyzer et régler les
paramètres de WAS
- mesurer de nouveau
Il faut voir qu'activer les mesures dans la base ou WAS a un coup, il
faut donc systématique re-mesurer sans le profiling pour assurer les
comparaisons entre les différentes étapes
Important: conserver toutes les mesures, et noter toutes les actions
prises. Cela permet de reproduire les améliorations, et
éventuellement comparé si le code de l'application est modifiée après
un premier tuning de perf.
--
Yves Martin
architecturales et de codage ....
si tu veux l'utiliser pour du test fais le .....
l'implementation meme des couches de serialisation/ et d'IO jouera sur
le ersultat final
plus le parametrage des -XMs -Xmx (valeurs proches conseillees)
la strategie de garbage collector..
l'inlining de code....
j'en passe
pool oblige)
--
Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003
http://www.eyrolles.com/php.informa...?ouv_ean1382212111941
architecturales et de codage ....
alors pourquoi tu penses que c'est mal adapté pour un bechmark ?
(il y a un rapport avec les EJB ?)
* Je vais acheter ton livre tome2 (et tome1 aussi)
"jerome moliere" news:c0vb7v$2ca7$