Discussion :

[fxrobin]

je pense que ta conclusion est bonne.

[VinceSSJ]

Donc n'y a t'il pas un problème de conception ? Ou est ce que le fait de ne pas avoir de ear est tout à fait normal ?

[VinceSSJ]

Je retire en partie ce que j'ai dit. Sur le serveur en prod il y a bien un EAR que je vois dans NetBeans, mais aucune trace de lui sur la console d'ami Glassfish

[VinceSSJ]

Je retire TOUT ce que j'ai dit !!

En réalité il y a un bien un EAR sauf qu'effectivement il n'était pas dans le dossier qu'on m'a passé. Donc je l'ai recontruit avec Netbeans, et au déploiement tout est OK !!!!!! l'appli tourne sur mon poste
Donc l'histoire des EJB @remote sont toujours d'actualité puisque c'est le même EAR

Bref merci beaucoup fxrobin tu m'as mis sur la bonne voie à chaque fois

et cerise sur le gateau, les lenteurs de la prod sont aussi présentes. En 2 fois plus long même

Et deuxième cerise, je peux la profiler Yourkit m'indique les requêtes utilisées, leur cout, leur nombre d'invocations.. Bref, maintenant va falloir que je sache si c'est le framework qui mouline ou bien le code métier

[fxrobin]

Bon et bien tu es sur la bonne voie
Maintenant, ça va être plus compliqué : identifier avec certitude, le ou les points "bloquants".

Parfois c'est une somme de "petits" points bloquants qui causent des ralentissements, ça c'est le plus difficile à trouver.

Parfois tu vas trouver LE point bloquant ... et il sera au coeur de l'architecture retenue et le corriger peut s'avérer très difficile si la conception n'a pas été suffisamment modulaire ...

Bref, tu as du taf en perspective

Sans compter les optimisations que tu penseras justes et qui :
- ne changeront rien
- dégraderont les perfs

bref profiler une application qu'on pas faite sois-même, ça peut être très très ardu ... je te souhaite quand même d'y arriver.

Commence par mettre -server dans les jvm-options de ton domain.xml, et augmente la RAM avec Xms et Xmx. Attentions certaines options de JVM ne sont pas compatibles entre elles. Va lire les docs que je t'ai données à ce sujet.

@+ et tiens nous au courant.

[VinceSSJ]

Oui j'ai l'impression que le plus dur reste à faire

Je constate que les lenteurs sont vraiment 3 voire 4 plus longues sur ma machine ce qui va me permettre d’exagérer les points faibles de l'appli pour en sortir quelque chose... j'espère

Je viens de regarder un peu avec Yourkit, j'ai testé la construction d'un emploi du temps et le chargement d'une liste de tâche ce qui donne :
au niveau des rendus des requêtes SQL ça donne ça:
image
La première a un temps de 20000ms ?!

au niveau des servlets :
image
La les résultats semblent logiques puisque les 2 servlets les + utilisés correspondent bien aux 2 fonctionnalités testée

Et au niveau des "Hots Spots" rencontrés
image

Est ce que à vu d'oeil selon toi déjà là les résultats te semblent mauvais ? Je t'en demandes peut être trop là mais merci d'avance
Pour moi les résultats me semblent énormes mais bon.. pour l'instant je peux pas trop être objectif sachant que c'est la première appli JEE que j'étudie/profile

En attendant je vais toucher à la doc que tu m'as passé la page d'avant

[fxrobin]

Une requête qui fait 20 secondes c'est énorme.

Maintenant il faut que tu regardes si elle te retourne bcp d'informations, ou si c'est son traitement qui est long (voire les deux).

Combien de row retourne cette requête ?
Connecte ton NetBeans à ton SQLServer et lance les mêmes requêtes pour voir si les temps de réponse son aussi long. Si oui, il faudra optimiser la requête, ce qu'elle retourne, et la structure de la base (en terme d'index)

As-tu bien des index, et de vraies jointures (LEFT JOIN, INNER JOIN) dans cette requête ?

Si tu la relance une seconde fois, elle est aussi longue ?

Ton projet utilise un système de persitence genre Hibernate ?
Dans tous les cas j'investiguerai plutôt côté SQL Serveur pour le coup.

[fxrobin]

est-ce que ton cache JPA est actif ?
Quelle est l'implémentation choisie ? Hibernate ?

si oui :
- http://weblogs.java.net/blog/caroljm...21/jpa-caching
- http://blog.dynatrace.com/2009/02/16...e-query-cache/

[VinceSSJ]

Alors pour répondre à tes questions,

-Sachant que JEE 6 est sorti en 2009 et que l'appli a été développée courant 2008, j'en déduis que c'est Java EE 5 d'utilisé
-Les EJB sont des 3.0. D'après ce que j'ai vu les 3.1 n'ont même plus besoin d'interfaces en local et on peut les mettre dans le war donc à voir.
-le cache : aucune idée, ce n'est mentionné nulle part dans la doc technique.. comment voir si c'est activé quelque part ?
-Sur le serveur en prod, c'est Sun Java System Application Server 9.1_02 soit Glassfish v2(ur2)
Sur ma machine c'est Glassfish 3.0.1 (build 22)

[fxrobin]

peux tu montrer ton fichier "persistence.xml" ?
(attention à ne pas reproduire login et password ) s'il y en a.

[VinceSSJ]

Où se trouve ce fichier ?
C'est bien celui là ? http://glassfish.java.net/javaee5/pe...e-support.html

J'ai beau chercher dans tous les jar et ear je ne le trouve pas

[fxrobin]

normalement dans le répertoire META-INF de ton ejb-jar
sous NetBeans tu dois le voir dans "configuration files" ...

t'es sûr que la persistence est faite avec JPA pour le coup ?
Le fait que tu soies en EJB Session n'impose pas JPA pour les entités. Si sa se trouve tu es en Hibernate pur et dur. As-tu un fichier de configuration Hibernate qui traine ?

As-tu le document d'architecture de l'application ?

[VinceSSJ]

Aucune trace du persistence.xml.. même d'un hibernate !!

Qu'est ce que je peux en conclure ?

Voici le dossier de l'ejb-jar :

[fxrobin]

comme dis en MP, que tu es en JDBC pur ...
donc pour mettre en oeuvre un cache il faudra un peu "bosser" et par exemple utiliser ehcache :

http://ehcache.org/documentation/integrations/jdbc

[VinceSSJ]

C'est noté
Comme dit en MP j'aimerais avoir ton avis sur ce que tu considères comme aberration

Je vais déjà essayer de mettre en place un cache.. Chaud devant