Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Langage Java Performances J2EE

Performances J2EE

8 réponses
Avatar
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
Signaler un problème avec ce contenu

8 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
jerome moliere
Utilisateur1 wrote:

Bonjour à tous (et à toutes aussi),

Je précise que je suis NUL en Java (je ne le connais pas) !!


ca peut arriver :)
Je cherche des idées dans le cadre de mon mémoire autour des performances
des applications J2EE.


ton memoire part bien alors :)
racontes nous cela...
Ne savant pas par quoi commencer et n'étant pas programmeur java j'ai pris
l'application petstore 1.2 (de SUN).


quelle bonne idee :)
bencher avec quelque chose de specialement mal adapte pour cela....
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 ?


ah voila une bonne question....
On peut parler aussi de la comparaison polimique entre petstore et petshop
(.net) : mais c'est un sujet existant.

je peux vraiment pas rajouter mon lot de conneries dites a ce sujet ?

dommage....
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 ?



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....
Cdt,
Yhab




jerome
--
Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003
http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_ean13—82212111941

Avatar
Utilisateur1
Jerome, si tu as un avis a donner (différent de ce qui est connu) sur le
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" a écrit dans le message de
news:c0osfp$1a1t$
Utilisateur1 wrote:

Bonjour à tous (et à toutes aussi),

Je précise que je suis NUL en Java (je ne le connais pas) !!


ca peut arriver :)
Je cherche des idées dans le cadre de mon mémoire autour des
performances


des applications J2EE.


ton memoire part bien alors :)
racontes nous cela...
Ne savant pas par quoi commencer et n'étant pas programmeur java j'ai
pris


l'application petstore 1.2 (de SUN).


quelle bonne idee :)
bencher avec quelque chose de specialement mal adapte pour cela....
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 ?


ah voila une bonne question....
On peut parler aussi de la comparaison polimique entre petstore et
petshop


(.net) : mais c'est un sujet existant.

je peux vraiment pas rajouter mon lot de conneries dites a ce sujet ?

dommage....
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 ?



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....
Cdt,
Yhab




jerome
--
Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003

http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_ean13—82212111941





Avatar
Yves Martin
"Utilisateur1" writes:

Jerome, si tu as un avis a donner (différent de ce qui est connu) sur le
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


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

Avatar
jerome moliere
Utilisateur1 wrote:

Jerome, si tu as un avis a donner (différent de ce qui est connu) sur le
match petshop (.net)/petstore (j2ee) dit le stp...
le petstore est une appli faite pour demontrer des best practices

architecturales et de codage ....
si tu veux l'utiliser pour du test fais le .....
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
clairement

- de la JVM : ???
evidemment....typiquement dans le cadre d'un serveur d'appli

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
- du garbage collector ???
- du jdbc ?
bien entendu, choix du driver, liberation des connexions (passage par un

pool oblige)
- 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 ?
oui....

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" a écrit dans le message de
news:c0osfp$1a1t$

Utilisateur1 wrote:


Bonjour à tous (et à toutes aussi),

Je précise que je suis NUL en Java (je ne le connais pas) !!


ca peut arriver :)

Je cherche des idées dans le cadre de mon mémoire autour des



performances

des applications J2EE.


ton memoire part bien alors :)
racontes nous cela...

Ne savant pas par quoi commencer et n'étant pas programmeur java j'ai



pris

l'application petstore 1.2 (de SUN).


quelle bonne idee :)
bencher avec quelque chose de specialement mal adapte pour cela....

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 ?


ah voila une bonne question....

On peut parler aussi de la comparaison polimique entre petstore et



petshop

(.net) : mais c'est un sujet existant.



je peux vraiment pas rajouter mon lot de conneries dites a ce sujet ?
dommage....

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 ?



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....

Cdt,
Yhab




jerome
--
Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003



http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_ean13—82212111941






--
Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003
http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_ean13—82212111941



Avatar
Utilisateur1
Puisque le petstore est faite pour demontrer des best practices
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" a écrit dans le message de
news:c0vb7v$2ca7$
Utilisateur1 wrote:

Jerome, si tu as un avis a donner (différent de ce qui est connu) sur le
match petshop (.net)/petstore (j2ee) dit le stp...
le petstore est une appli faite pour demontrer des best practices

architecturales et de codage ....
si tu veux l'utiliser pour du test fais le .....
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
clairement

- de la JVM : ???
evidemment....typiquement dans le cadre d'un serveur d'appli

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
- du garbage collector ???
- du jdbc ?
bien entendu, choix du driver, liberation des connexions (passage par un

pool oblige)
- 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 ?
oui....

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" a écrit dans le message de
news:c0osfp$1a1t$

Utilisateur1 wrote:


Bonjour à tous (et à toutes aussi),

Je précise que je suis NUL en Java (je ne le connais pas) !!


ca peut arriver :)

Je cherche des idées dans le cadre de mon mémoire autour des



performances

des applications J2EE.


ton memoire part bien alors :)
racontes nous cela...

Ne savant pas par quoi commencer et n'étant pas programmeur java j'ai



pris

l'application petstore 1.2 (de SUN).


quelle bonne idee :)
bencher avec quelque chose de specialement mal adapte pour cela....

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 ?


ah voila une bonne question....

On peut parler aussi de la comparaison polimique entre petstore et



petshop

(.net) : mais c'est un sujet existant.



je peux vraiment pas rajouter mon lot de conneries dites a ce sujet ?
dommage....

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 ?



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....

Cdt,
Yhab




jerome
--
Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003




http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_ean13—82212111941








--
Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003

http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_ean13—82212111941







Avatar
Utilisateur1
Si j'ai bien compris : Tu penses que les perfs dépendent peu du code ?
Tu veux dire plutôt que la phase de conception (UML par ex) ne dépend pas
des perfs
Dans le magazine java report (2001, Volume 6, number 9) :
Ils ont mesurer les perfs de code java écrits différement :
prepared statements au lieu de statement, BufferString au lieu de String et
ça change tout au niveau temps d'exécution
==> Je t'envoie les exemples donnés (moi je suis DEBUTANT)
Est-ce que tu conseilles d'utiliser le profiler OPTIMISEIT pour la partie
JVM, et garbage collector ?
(je ne connais pas non plus ce profiler)

Je tiendrais aussi compte de tes remarques même si je ne suis pas persuadé
Car en général, dans les applis on utilise un pool de connexions limité (par
l'administrateur) à un max de 25 pour la
plupart des applis ==> On aura un maximum de 25 sessions en // en BD, même
si le nbr de sessions
simultannées dépasse largement 25 ==> le goulet d'étranglement est côté
serveur d'applications et pas côté BD (sauf si la BD n'est
pas dimensionnée pour supporter 25 sessions faisant des requêtes lourdes).

* Tout mon truc c'est pour présenter un mémoire autour des perfs en sachant
que suis débutant en java.


"Yves Martin" a écrit dans le message de
news:
"Utilisateur1" writes:

Jerome, si tu as un avis a donner (différent de ce qui est connu) sur le
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


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



Avatar
Yves Martin
"Utilisateur1" writes:

Si j'ai bien compris : Tu penses que les perfs dépendent peu du code ?
Tu veux dire plutôt que la phase de conception (UML par ex) ne dépend pas
des perfs
Dans le magazine java report (2001, Volume 6, number 9) :
Ils ont mesurer les perfs de code java écrits différement :
prepared statements au lieu de statement, BufferString au lieu de String et
ça change tout au niveau temps d'exécution
==> Je t'envoie les exemples donnés (moi je suis DEBUTANT)
Est-ce que tu conseilles d'utiliser le profiler OPTIMISEIT pour la partie
JVM, et garbage collector ?
(je ne connais pas non plus ce profiler)


Effectivement, j'ai supposé que le code était écrit au départ en
respectant tous les guidelines connus concernant les performances -
Sun les donne quelque part, c'est sûr. Effectivement,
PreparedStatement, StringBuffer et autres finesses.

OptimizeIt ne te permettra pas de savoir comment écrire du bon code -
mieux vaut lire un bon livre: j'ai "Mieux programmer en Java" chez
Eyrolles - 68 astuces présentés sous forme d'atelier avec exemples
pour éviter les plus gros pièges.

OptimizeIt te permettra par contre de savoir où ton code a un
problème (mauvais boucle, créations d'objets temporaires abusifs...)
pour atteindre tes objectifs de perf - qu'il vaut mieux définir au
début.

Une fois ton code épuré on passe au paramétrage du container EJB (que
j'ai décrit avant) - il peut rester qq défauts dans le code mais ce
n'est en général pas l'essentiel si on ne les détecte pas avec un
profiler de code.

Attention: configurer le GC doit être fait en dernier recourt, quand
on ne trouve plus aucune amélioration possible à faire dans le code -
côté mémoire: création/destruction/copie d'objets.

Je tiendrais aussi compte de tes remarques même si je ne suis pas persuadé
Car en général, dans les applis on utilise un pool de connexions limité (par
l'administrateur) à un max de 25 pour la
plupart des applis ==> On aura un maximum de 25 sessions en // en BD, même
si le nbr de sessions
simultannées dépasse largement 25 ==> le goulet d'étranglement est côté
serveur d'applications et pas côté BD (sauf si la BD n'est
pas dimensionnée pour supporter 25 sessions faisant des requêtes lourdes).


Hum. J'ai déployé des serveurs Servlet/EJB utilisé par 200
utilisateurs en parallèle, et un pool de 100 Connection était
largement nécessaire...

Autre aspect particulier de WebSphere: la taille du cache des
PreparedStatement... si on utilise beaucoup de requêtes différentes,
il faut peut-être l'augmenter.

Si c'est le serveur EJB qui est bloqué et que la base dort, il y a
surement qq chose à faire dans le code ou dans le design de
l'application:
- ResourceAnalyzer permet de voir si des moniteurs/synchronized ne
bloque pas qq part - voir avec le ThreadDebugger d'OptimizeIt
aussi.
- Les traces d'activités du GC permettent de savoir si on bloque à
cause de la mémoire ou simplement que le CPU est saturé pour les
traitements métier qu'il faut optimiser peut-être.

Le modèle de données est aussi important dans cette chaîne
multi-tiers: grosses jointures réalisées par la base ou alors le code
fait beaucoup de petites requêtes plutôt que d'utiliser une jointure,
un curseur ou une procédure stockée (certes ce n'est plus l'exigence
de portabilité de JDBC qui prime mais la perf dans ce cas)

Très sincèrement, le profiling de code et le paramétrage d'un
containeur EJB sont très intéressants mais difficiles à appréhender
lorsque l'on débute en Java: il faut connaître un minimum le
fonctionnement de la JVM et du GC mais aussi comment fonctionne un
serveur J2EE. Bref, beaucoup de livres et docs à lire.

IBM fournit pas mal de RedBook sur son site pour le tuning du GC et
de WebSphere. Ils ne sont pas faciles à trouver mais ils sont très
pratiques:

http://www-306.ibm.com/software/webservers/appserv/was/library/

Recherche des RedBooks:
http://www-1.ibm.com/support/search.wss?rs0&tc=SSEQTP&dcÚ700
Mot clef: "tuning"

En dernier ressort, le GC:
http://www-106.ibm.com/developerworks/ibm/library/i-gctroub/

A+
--
Yves Martin

Avatar
Utilisateur1
Eh bien merci beaucoup, il y a matière à travailler (beaucoup de choses à
lire pour commencer).
J'ai trouvé de + 1 référence chez O'reily (Java Performance Tuning).

Dans ce que tu as dit :
Positionner un pool à 100 cnx simultannées donc potentiellement autour de
2500 http requests (ou 2500 bonhommes qui utilisent l'appli)
Dans ce cas, le goulet est sur le jdbc !
C'est pour celà que je le positionne à 25 pour éviter de saturer le tuyau
vers la BD et l'autre raison est la mutualisation des ressources.
Yhab

"Yves Martin" a écrit dans le message de
news:
"Utilisateur1" writes:

Si j'ai bien compris : Tu penses que les perfs dépendent peu du code ?
Tu veux dire plutôt que la phase de conception (UML par ex) ne dépend
pas


des perfs
Dans le magazine java report (2001, Volume 6, number 9) :
Ils ont mesurer les perfs de code java écrits différement :
prepared statements au lieu de statement, BufferString au lieu de String
et


ça change tout au niveau temps d'exécution
==> Je t'envoie les exemples donnés (moi je suis DEBUTANT)
Est-ce que tu conseilles d'utiliser le profiler OPTIMISEIT pour la
partie


JVM, et garbage collector ?
(je ne connais pas non plus ce profiler)


Effectivement, j'ai supposé que le code était écrit au départ en
respectant tous les guidelines connus concernant les performances -
Sun les donne quelque part, c'est sûr. Effectivement,
PreparedStatement, StringBuffer et autres finesses.

OptimizeIt ne te permettra pas de savoir comment écrire du bon code -
mieux vaut lire un bon livre: j'ai "Mieux programmer en Java" chez
Eyrolles - 68 astuces présentés sous forme d'atelier avec exemples
pour éviter les plus gros pièges.

OptimizeIt te permettra par contre de savoir où ton code a un
problème (mauvais boucle, créations d'objets temporaires abusifs...)
pour atteindre tes objectifs de perf - qu'il vaut mieux définir au
début.

Une fois ton code épuré on passe au paramétrage du container EJB (que
j'ai décrit avant) - il peut rester qq défauts dans le code mais ce
n'est en général pas l'essentiel si on ne les détecte pas avec un
profiler de code.

Attention: configurer le GC doit être fait en dernier recourt, quand
on ne trouve plus aucune amélioration possible à faire dans le code -
côté mémoire: création/destruction/copie d'objets.

Je tiendrais aussi compte de tes remarques même si je ne suis pas
persuadé


Car en général, dans les applis on utilise un pool de connexions limité
(par


l'administrateur) à un max de 25 pour la
plupart des applis ==> On aura un maximum de 25 sessions en // en BD,
même


si le nbr de sessions
simultannées dépasse largement 25 ==> le goulet d'étranglement est côté
serveur d'applications et pas côté BD (sauf si la BD n'est
pas dimensionnée pour supporter 25 sessions faisant des requêtes
lourdes).



Hum. J'ai déployé des serveurs Servlet/EJB utilisé par 200
utilisateurs en parallèle, et un pool de 100 Connection était
largement nécessaire...

Autre aspect particulier de WebSphere: la taille du cache des
PreparedStatement... si on utilise beaucoup de requêtes différentes,
il faut peut-être l'augmenter.

Si c'est le serveur EJB qui est bloqué et que la base dort, il y a
surement qq chose à faire dans le code ou dans le design de
l'application:
- ResourceAnalyzer permet de voir si des moniteurs/synchronized ne
bloque pas qq part - voir avec le ThreadDebugger d'OptimizeIt
aussi.
- Les traces d'activités du GC permettent de savoir si on bloque à
cause de la mémoire ou simplement que le CPU est saturé pour les
traitements métier qu'il faut optimiser peut-être.

Le modèle de données est aussi important dans cette chaîne
multi-tiers: grosses jointures réalisées par la base ou alors le code
fait beaucoup de petites requêtes plutôt que d'utiliser une jointure,
un curseur ou une procédure stockée (certes ce n'est plus l'exigence
de portabilité de JDBC qui prime mais la perf dans ce cas)

Très sincèrement, le profiling de code et le paramétrage d'un
containeur EJB sont très intéressants mais difficiles à appréhender
lorsque l'on débute en Java: il faut connaître un minimum le
fonctionnement de la JVM et du GC mais aussi comment fonctionne un
serveur J2EE. Bref, beaucoup de livres et docs à lire.

IBM fournit pas mal de RedBook sur son site pour le tuning du GC et
de WebSphere. Ils ne sont pas faciles à trouver mais ils sont très
pratiques:

http://www-306.ibm.com/software/webservers/appserv/was/library/

Recherche des RedBooks:
http://www-1.ibm.com/support/search.wss?rs0&tc=SSEQTP&dcÚ700
Mot clef: "tuning"

En dernier ressort, le GC:
http://www-106.ibm.com/developerworks/ibm/library/i-gctroub/

A+
--
Yves Martin