Lenteur application WEB

Bonjour,

Je gère actuellement une application WEB intranet avec JSF/J2EE.
L'application utilise le JDK 1.5 et hibernate pour accéder à une base Oracle.

L'application est développée sous l'EDI NetBeans 5.5.
L'application utilise un serveur d'application JONAS (peut-être cause du problème) ?
Elle se compose d'une page d'accueil de recherche et après recherche possibilité d'avoir le détail d'un client sous forme d'onglets.

Problème 1 : le passage sur la page des onglets est relativement lent (10 secondes).
Problème 2 : le passage d'un onglet à un autre est relativement lent (10 secondes).

Savez-vous comment optimiser ces temps de réponse ?

Solutions proposées
1) Je pensais faire migrer l'application sur un serveur WAS IBM ?
2) Il il y a peut-être un mauvais paramétrage d'hibernate ?

Autres solutions?

Merci par avance pour votre retour.

1) passer hiberante en show SQL à true, ca permettera de voir si il n'est pas mal configuré et qu'il "pompe" l'intégralité de la DB à chaque requete http
2) regarder du coté du composant utilisé pour faire les onglets
3) activer éventuellement le cache de deuxième niveau d'hibernate.


Les coupables, sur les performance d'une page JSF, sont à chercher principalement en général dans les performance des getters des beans, ceux-ci étant très sollicités par JSF


A noter que, dans le cadre d'un interface complexe, j'ai l'expérience d'un lenteur similaire: on voyais le début de la page, puis fallait attendre presque 30 secondes pour avoir le rich:tabbedPane visible. Après moulte mesure, il s'est avéré que notre serveur renvoyais bien au client la page en moins d'une seconde, mais que internet explorer passait 30 secondes à faire ses calculs CSS. Firefox affichait la page instantanément lui :aie:


Ce n'est pas en changeant le conteneur (qui lui ne fait qu'une infime partie du travail de la requete) que tu va gagner 10 secondes :)

Sous NetBeans, j'utilise Visual Web Pack.

1) Les onglets se caractérisent par une page fragment "jspf".
Il y a donc un bandeau et une page fragment pour représenter l'onglet.
2) Sur chaque onglet, il peut y avoir des composants du type suivant :
* tabset
* table
* label
* textfield

--> Composants JSF il me semble ?

3) Comment activer le cache de deuxième niveau sous Hibernate ?

4) Si je comprends bien le fait de changer de serveur d'application ne risque pas de changer grand chose ?

Merci pour vos réponses.

J'ajoute une réponse : en faisant un test sous firefox, cela ne change rien du tout en terme de performance.

IE 8 = FIREFOX 5....

il te faut identifier le probleme :

Regarder la cpu du serveur : si ça reste bas, c'est que c'est peut être réseau, ou lenteur base de base de données. si ca monte, c'est plus a chercher coté java

cpu/io de la base de données. (si tu peux tester avec une base presque vide par exemple : ca fait disparaître les problèmes de structure de base : si ca redevient rapide avec une base presque vide : surement un probleme d'index manquant)

OK merci pour ces infos.

Je n'ai pas accès au serveur car c'est l'exploitant qui gère les machines mais je vais leur demander.

Je ne pense pas que cela vienne de la base de données car une autre application qui accède à la même base avec une autre techno n'a pas des performances aussi basses.

--> Je pense que le problème est plutôt côté JAVA....
Mais excepté redévelopper l'application, je ne vois pas ce que je pourrais faire...?
Changer la version du JDK (problème de compatibilité) ....?

le tuning d'applications java est un sujet complexe. Sans acces au serveur : c'est encore plus compliqué

bon : les jsf ne sont pas un modele de tenue a la charge, mais normalement, ca marche quand meme.

les questions : ca rame quand ?
quand tu es tout seul sur l'application ou quand il y a beaucoup de monde ?
seul -> problème de code/conception même le pire des code java ne peux pas prendre 10 secondes a afficher un onglet
beaucoup -> probleme de scaling : ca dépasse le cadre de notre discussion

ca rame partout ? ou sur certains écrans
partout -> problème global (configuration serveur, réseau, conception)
a un endroit -> un morceau de code fait ramer ce truc : peut etre un acces mal fait a la base, de la concaténation de string en boucle etc...

sans acces au serveur : il faut que teste en local. si ca rame pas en local : probleme de conf serveur. sinon tu as des outils

netbeans profiler
eclipse http://www.eclipse.org/tptp/
Jprofiler
qui peuvent permettre de trouver ce qui coute cher en cpu lors de l'affichage

des fois : le simple fait de suivre le code se dérouler en mode debug peut te permettre de détecter des gros problèmes (passage multiples dans une méthode coûteuse etc...)

Et vos test unitaire, il montrent quoi coté performances pour l'accès à la couche de données?

Les tests en local sont aussi très lents.
On développe sous NETBEANS/Tomcat. C'est très lent.

Sur la qualification, le serveur n'est pas TOMCAT mais JONAS.

* Ca rame quand ? Tout le temps qu'on soit un ou plusieurs mais peut-être que cela se dégrade aussi en fonction du nombre d'utilisateurs.

* Ca rame partout ?
Sur l'écran d'accueil de recherche moins que sur les autres.
Sur les autres écrans beaucoup plus.
Page d'accueil->Onglet 1, Onglet 2, ...., Onglet N
Problème :
1) Lorsque l'on clique sur le bouton pour afficher les N onglets, tous les onglets sont initialisés en même temps (méthode "init" de la chaque page fragment) --> Donc on passe dans les n méthodes "init"...
2) Dans chaque méthode "init", on teste le profil de l'utilisateur pour gérer l'affichage des composants : modification/visualisation

Exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10

if(getSessionBean1().getArUser() != null) { if(getSessionBean1().getArUser().contains("ADMIN") || getSessionBean1().getArUser().contains("COMM")) { getSessionBean1().setReadonlyAdresses(Boolean.FALSE); } else getSessionBean1().setReadonlyAdresses(Boolean.TRUE); }

---

Je vais essayer de mettre NetBeans Profiler en espérant que je puisse l'installer sur une vieille version de NetBeans 5.5.1.

Voilà merci pour vos remarques ?

moué

a moins que derriere

Code:

---

.getArUser().contains("COMM")

---

vous ayez quelque chose de vraiment complexe, je ne vois pas comment ca pourrait faire ramer.

apres, si a chaque getArUser() tu as un acces en base, ou a autre chose de lent : c'est une bonne piste ;)

Pas possible d'utiliser le profiler sur la version 5.5.1 :(.

http://www.ej-technologies.com/produ.../overview.html
y'a une version d'essai de quelques jours... ca te laisse le temps de trouver ;)

ouais ou tu commente le bout de code suspect le temps du test :)

Et comme je l'ai dit, si vous utilisez hibernante -> activez l'affichage des requtes SQL, ca sera déjà un bon indicateur, si il fait 500 requetes SQL pour une demande web, vous aurez trouvé votre piste :)

OK merci je vais voir ce que cela donne avec cette version de JProfiler.

Pour expliquer le :

Code:

---

1 2	.getArUser().contains("COMM")

---

A la première connexion d'un utilisateur on appelle un webservices SSO qui met en session le profil de l'utilisateur, ce qui explique qu'on lit dans le "Bean Session" les données d'un ArrayList avant d'afficher la page. J'ignore si cela vient de là donc....

C'est une piste de désactiver le code tchize mais je ne pense pas que cela vienne de là, c'est simplement une lecture du Bean de session et c'est peut-être la lenteur des Bean en général ?

Concernant les requêtes SQL, nous avions déjà affiché à une époque le SQL sans résultat, c'est une base client (max 10000 lignes) donc les requêtes ne sont pas très complexes.
Ce qu'il y a c'est que le modèle de données est en étoile : à un client sont rattachées toutes les données annexes.

Client
-->Adresse
-->Contact
-->....

Donc en accédant à la page des N onglets, toutes les données sont récupérées mais impossible de changer le modèle.

donc si je suis bien, tu récupère 10.000 lignes * le nombre tables de données depuis la base à chaque requete HTTP et tu t'étonne que c'est lent?

En général c'est pas la complexité des requetes les problème avec les bases de données, mais la masse d'"information qui doit circuler dans la réponse :) Si vous pompez 50M sur la DB à chaque requete http, le réseau à intérêt à être solide, sans parler de la JVM qui dois stocker ça :mouarf:

Non pas du tout en fait 10 000 lignes c'est le nombre maximum de lignes d'une des tables de la DB.
On récupère au maxium une cinquantaine de lignes.....!

Sinon je viens d'installer jprofiler 6 qui apparemment ne gérait dans la liste que NetBeans 6 mais j'ai quand même tenté de l'installer pour NetBeans 5.
En lançant Jprofiler 5, j'ai le message d'erreur suivant :
could not connect to 127.0.0.1:8849
Please make sure that the remote server is correct,...

Il faut que je lance l'environnement NetBeans en parallèle en lançant mon projet j'imagine ?
Seul bémol mon serveur tomcat tourne sur le port 8080.....

Merci pour vos remarques.

c'est ton application web (donc tomcat) que tu profile, donc jprofiler tu lui demande de faire une profile pour tomcat, tu le démarrer avec jprofiler directement puis tu déploie dedans le war.


Pas besoin de se casser la nenette à rajouter netbeans dans l'équation pour juste faire des mesures :)

PS: de mémoire les docs de jprofiler étaient quand même très explicites à ce propos... Faut les lire :)

OK merci mais en fait tomcat est intégré à NetBeans donc pour démarrer tomcat je suis obligé d'ouvrir NetBeans....

Je vais voir si j'y arrive.

tomcat tourne dans une jvm séparée de netbeans, simplement netbeans fait sa configuration, suffit de regarder la doc de jprofiler, c'est indiqué ce qu'il faut ajouter comme paramètres à la jvm (celle de tomcat).

Impossible de démarrer tomcat avec jprofiler....
Il ne trouve pas la machine 127.0.0.1 sur le port 8080.

De plus, je n'arrive pas non plus à démarrer tomcat en dehors de NetBeans.
Donc je suis bloqué.....:(.

Si tu veux profiler le plus simple c'est d'utiliser jconsole.exe ou jvisualvm.exe
que tu trouveras dans Java\jdk1.6.0_23\bin

Sinon mets du log et trace les différente opérations et les durées en partant de la JSF ça donnera une bonne idée de ce qui prends du temps.

Mais je miserais sur hibernate qui choppe toute la base à chaque requête à cause d'une étourderie.