Version imprimable
Je viens d'installer le plugin, le noeud "Modèle" s'est affiché sous la JVM Glassfish dans VisualVM mais faux espoir, quand j'ai cliqué dessus : "impossible d'établir la connexion JMX" :aie:
Comment y remédier ? Quand je clique droit sur GlassFish je n'ai aucune option sauf le snapchot.
Yourkit lui il en fait encore moins puisqu'il arrive même pas à tracer les diagrammes..(il mouline quand il essaie de se connecter à son agent)
Ah mince.
Effectivement faut activer JMX sur la JVM de glassfish ... et donc la redémarrer.
T'as vraiment aucun moment pour faire ces manips ?
Genre à 04h00 du matin ... ? :D:D
Etant stagiaire je ne peux prendre aucune décision de la sorte :)
Je vais en parler à mon responsable pour voir ce qu'il en pense.
Sachant que l'appli est très utilisée dans l'entreprise ça va être dur de trouver un moment :calim2:
Bref sans JMX d'activer je ne peux rien faire.. C'est surement pour ça que Yourkit a du mal aussi :aie:
Si jamais on arrive à trouver 2minutes pour le redémarrer, comment s'y prendre pour activer JMX ? via domain.xml ?
En effet quand je le parcours le paramètre accept-all de la ligne jmx est à false. Je suppose qu'il faudrait le mettre à true ? Il n'y a que ça à faire ?
oui dans le domain.xml tu as les paramètres de lancement de ta JVM.
et voilà ce que tu dois appliquer :
http://docs.oracle.com/javase/1.5.0/...ent/agent.html
J'ai quand même quelques questions de fond.
Dans ton autre post tu disais qu'avec SpeedTracer tu avais des temps de réponse de génération de la page de l'ordre de 250 ms. Ce qui est plutôt bien.
Donc je te demandais quelle était la structure et le poids de la page, sa taille. N'est-ce pas plutôt le navigteur qui a du mal à l'afficher ? as-tu bcp de javascript ? As-tu aussi testé avec d'autres navigateurs ? (FireFox, Chrome, IE, ? toujours pareil au niveau de l'affichage ?)
Bon j'ai vu ça avec mon responsable j'aurai un petit créneau cet aprèm pour faire la manip'.
Pour répondre à ta question :
Au niveau de l'affichage des pages, déjà c'est explorer qui semble le plus lent, et chrome le plus rapide. Mais après la différence n'est pas flagrante et dans tous les cas les affichages des pages se fait vite. En fait ce qui pêche c'est le chargement des ressources, par exemple :
Je suis sur un emploi du temps vide et je Je veux charger un emploi du temps déjà construit, je sélectionne les éléments que je veux charger dans des listes déroulantes puis je clique sur un bouton pour valider. C'est à ce moment que le chargement prends plusieurs secondes : une progress bar indique la progression et donc au bout de plusieurs secondes les "tâches" chargées s'affichent sur l'emploi du temps.
Ces temps de chargement sont présents quasiment partout, pour charger une listes de tâche, en déplacer ces tâches sur l'emploi du temps, etc.
Et pour finir, oui il y a beaucoup de javascript puisqu'il n'y a que ça !! Il n'y a aucune JSP dans l'appli, seulement des servlet qui renvoie des codes html avec les body vides. Ce sont ensuite les fichiers javascript qui font tout le boulot
Avec SpeedTracer tu dois aussi pouvoir voir les temps de réponse lorsque tu cliques sur tes listes déroulantes.
Ca donne quoi là ?
autre question encore, la JVM de GlassFish est bien lancée en mode Serveur ? (option -server). Quels sont ses paramètres d'ailleurs à ta JVM : (Xmx, Xms, etc.)
enfin, envisage une migration de JVM vers une plus récente.
Je crois me souvenir qu'à partir de la 1_6_18, il y a eu un vrai plus en performances (genre +10 %)
Avec SpeedTracer, quand je clique sur les listes et que je choisis un élément rien ne se passe.
Sinon, comment et où voir si Glassfish est lancé en serveur ? l'outil d'admin en ligne me le montre ça ?
Sinon pour xmx, xmx.. je ne vois pas ce que c'est donc là faut que je me documente :aie:
Et enfin, oui il faudrait bien mettre à jour tout ça. Même Glassfish est en V2 et donc est à mettre à jour non ?
Par contre j'ai lu la doc que tu m'as passée mais je ne vois pas trop quoi faire pour activer JMX.. Je pensais qu'il fallait changer la valeur du domain.xml mais il n'en parle pas dans la doc ?!
EDIT : en me posant la question tout à l'heure sur javascript, ne voulais tu pas me dire qu'en réalité ce n'est pas le Framework qui est en cause mais plutôt les traitements de fond ?
domain.xml c'est pour GlassFish,
dedans tu as une section spécifique pour le paramètre de la JVM, c'est là que tu rajoute les arguments pour JMX
parce que le JavaScript, si c'est mal codé, ça peut très vite devenir un gros problème de performance et là c'est pas ton appli côté serveur qui est en cause mais les scripts côté client.Citation:
Envoyé par VinceSSJ
Ce sont des scripts perso ?
Donc d'après tout ce que j'ai dit jusqu'à maintenant pour toi le lenteurs de l'appli sont du au javascript ?
Comme je l'ai toutes les pages sont faites en javascript. Le framework utilisé est EXT JS 2.1, donc qui date de 2008. Cette version était la première "vraie" version puissante mais aussi très lourde à mettre en place (ça se comprend en voyant le code.). Le tout est bien évidemment couplé à de l'AJAX.
Bref par exemple la grille de l'emploi du temps de l'appli est entièrement codée à la main dans un servlet = code lourd.
En fait, là il faut que je fasse un choix car je n'ai plus que 3mois pr optimiser l'appli.
1-
Soit j'oriente mon développement vers l'optimisation du framework : j'ai en tête de remplacer EXT 2.1 par jQuery (dernière version) et de remplacer ainsi la grille de l'emploi du temps par un plugin de jQuery qui propose un calendrier préconstruit et des drag&drop bien sympas : http://arshaw.com/js/fullcalendar-1....-dragging.html
Le truc est toutes les pages sont faites en javascript donc ça oblige une refonte de toutes les pages..
2-
Soit j'oriente mon développement sur la remise des EJB en @Local (ils sont actuellement en remote alors qu'ils sont dans la même jvm) ainsi qu'une optimisation des requêtes SQL.
Je précise qu'il y a quelques temps les BD ont été nettoyées de toutes les archives ce qui avaient déjà accéléré les chargements de l'appli.. mais ils restent encore trop longs..
Difficile à dire sans voir l'appli fonctionner
Si tu as des échanges AJAX SpeedTracer devrait les voir ... étrange.
Donc si ça se trouve tes Combo Box ne sont même pas pleuplées en AJAX ... et donc le côté "serveur" serait à écarter.
Je te conseille de dupliquer l'appli / base de données pour travailler sur un autre serveur que le serveur de production et pour pouvoir changer les options de JVM de GlassFish.
qqs liens :
- http://java.developpez.com/cours/
- http://java.developpez.com/faq/
- http://docs.oracle.com/cd/E19747-01/...html#wp1101636
Mais oui je vais copier l'appli sur ma machine !!! Comment n'y ai-je pas penser plus tôt ? Surtout que des BD dupliquées ont été mises en place et vont pouvoir me permettre de faire des tests.
De plus je pourrai utiliser VisualVM et Yourkit sans problème sur mon poste.
Le problème, toujours, c'est que je n'aurai peut être pas les mêmes résultats que la production...
Bonjour,
j'ai copié l'appli sur mon poste puis j'ai essayé de la déployer et de la lancer avec mon GlassFish v3.
Comment lancer correctement une appli qui contient un war, une lib d'interfaces et un jar qui contient les EJB ? Le tout avec Netbeans
Sur le serveur en prod il y a la Web Appli et les EJB de déployer. Mais quand je veux déployer mes EJB ça marche pas..
Voici la console Glassfish quand j'essaie de lancer mon jar EJB (mon WAR s'est bien déployé lui) :
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
Il te dit que tu n'as pas d'EJB dans ton EJB-JAR, et qu'il en faut au moins un.
T'as dû oublier qqch quand tu as "tout" copier ;)
tu as copié l'EAR de la production, où tu es juste en train de tester un EAR "vide" ?
Si c'est le second cas il te faut créer un "vrai / faux" EJB, temporaire, juste pour que ton EJB-JAR se déploie
genre :
Code:
2
3
4
5
6
7
8
9
Ca c'est quasiment certain ;-)Citation:
Envoyé par VinceSSJ
Si sur ton poste tu as les mêmes temps de latence au début, ce sera bien, comme ça tu pourras investiguer correctement ;-)
Oh que oui je prie pour avoir les mêmes ralentissement qu'en prod mais bon.. je verrai bien :)
Pour l'instant j'essaie de déployer l'appli sur mon poste :aie:
En fait, mon responsable m'a passé le dossier "source" de l'appli.
Il contient 3 projets et c'est tout : un EJB-jar, un War, et un jar contenant les interfaces (et sinon tous les dossiers des classes et fichiers etc...)
Dans l'EJB-jar, j'ai regardé et il y a bien le EJBremonte-jar qui contient toutes les interfaces.
Donc en réalité je n'ai aucun ear ?!
En prod sur Glassfish il n'y a que le War et l'EJB-jar de déployés. Donc j'ai essayé de faire pareil, mon War se déploie nickel mais ça coince pour les EJB.
En fait même si j'ai compris ce qu'est un EAR je ne le vois pas physiquement, ni comment le créer, sachant que jusqu'à maintenant je ne l'ai vu nul part même en prod !!!
En effet, même en prod, quand je vais sur la console d'admin de GlassFish, dans la liste Enterprise Applications (liste des EAR) il n'y a rien ! 8O
Il y a juste un projet Web applications (le war) et un ejb module (EJB-jar)
J'ai du mal à comprendre.. Dois-je en déduire que le dev de l'appli n'avait pas fait de EAR ? Ce qui expliquerait que les EJB sont en Remote ??