Problémes de performances struts / HTML

Version imprimable

20/10/2006, 18h21
sky_striker

Problémes de performances struts / HTML

Bonjour à tous et merci d'avance pour votre aide :

Voila j'ai une application weblogic communiquant avec une base oracle pouvant potentiellement contenir 1 000 000 d'éléments.

Comme vous vous en doutez j'ai des problémes de performances assez dramatiques.

J'affiche les éléments de manière paginé sur mon application WEB géré par struts. Le probléme est que quelqu'un a eu la lamentable idée de donner la possibilité à l'utilisateur d'afficher cette liste de maniére dépaginé (tout les éléments d'un seul coup). Je précise que je pratique un troncage de la liste à 1000 éléments maximun en fonction de critéres de recherche par le bias d'un rownum.

Les problèmes sont diverses :
- La page HTML généré ne l'est pas en moins de 9 minutes en local et 5 sur mon serveur ce qui bien évidement trop long
- La taille de la page généré approche les 6.5 Mo ce qui rend le parsing trés lent
- Même si le nombre d'éléments de la liste ne parait pas excessivement grand les 1000 éléments contiennent eux aussi des sous éléments ce qui donne en struts deux boucle imbriqués sur des objets "complexes".
- Enfin point important ce n'est pas ma couche métier/donnée qui pénalise les perf car au moment de la dépagination la liste est déjà en mémoire. ce qui m'améne à penser que c'est le struts lui même ainsi que le parsing qui sont long
- Enfin dernier point il y a des actions qui sont gérées en javascript sur les éléments (chaque liste de sous éléments pouvant être affiché/masqué selon les besoins) ce qui génére encore plus de texte sur la page :-(

J'ai entreprit de faire un maximun de "ménage" dans les pages JSP de supprimer le recourt au tiles qd ceux-ci ne sont pas absolument necessaires. De remettre au propre le code struts mais les gains ne sont pas énormes aux plus un poigné de secondes (une 20 aine).

Que puis-je faire ? en dehors de demander à mon chef de projet de se faire cuire un oeuf pour qu'il le répéte au client. La conclusion est bien évidement que le travail est long et que donc il est normal que cela prenne du temps mais bon je dois essayer.

Vos remarques, liens, docs seront les bienvenus.

Voila éclairez ma lanterne SVP ...
20/10/2006, 22h08
azerr

Bonsoir sky_striker,
je pense que tu devrais deja essayer de recuperer le code source de ta page, de l'enregistrer dans une page html et de l'ouvrir avec ton navigateur pour vérifier si tu peux ameliorer les performances ou non. Si ca mets 15 ans aussi pour afficher la page, enleve le javascript qui gere le masquage de tes champs, si ca mets 15 ans, j'ai bien peur que tu ne puisses rien faire.
Si en enlevant le javascript, tu gagnes en performances, tu devrait peut etre gerer tes masquages de tes champs au niveau du serveur?

Si ta page HTML a des temps de reponses correcte, verifie que c'est bien la generation de ta JSP, qui prends du temps (en metant new Date au debut et a la fin de ta page et en comparant les temps).

En tou cas (je sais que ca n'est pas toi qui a choisi cette solution), c'est une hérésie de vouloir afficher 1000 enregistrements sur une page, meme pour l'utilisateur ca devient infernal pour retrouver son enregistrement.

Peut etre devrais tu proposer a ton chef de projet de mettre des criteres de recherches pertinents, pour donner la possibilite de retourner tous les enregistrements (sans pagination mais filtres par des criteres)

Angelo
23/10/2006, 10h12
sky_striker

Citation:

Envoyé par azerr

Bonsoir sky_striker,
je pense que tu devrais deja essayer de recuperer le code source de ta page, de l'enregistrer dans une page html et de l'ouvrir avec ton navigateur pour vérifier si tu peux ameliorer les performances ou non. Si ca mets 15 ans aussi pour afficher la page, enleve le javascript qui gere le masquage de tes champs, si ca mets 15 ans, j'ai bien peur que tu ne puisses rien faire.
Si en enlevant le javascript, tu gagnes en performances, tu devrait peut etre gerer tes masquages de tes champs au niveau du serveur?

Si ta page HTML a des temps de reponses correcte, verifie que c'est bien la generation de ta JSP, qui prends du temps (en metant new Date au debut et a la fin de ta page et en comparant les temps).

En tou cas (je sais que ca n'est pas toi qui a choisi cette solution), c'est une hérésie de vouloir afficher 1000 enregistrements sur une page, meme pour l'utilisateur ca devient infernal pour retrouver son enregistrement.

Peut etre devrais tu proposer a ton chef de projet de mettre des criteres de recherches pertinents, pour donner la possibilite de retourner tous les enregistrements (sans pagination mais filtres par des criteres)

Angelo

Bonjour,

Je te remerci de ta réponse j'essais ce que tu me demandes et je te tiens au courant.

Cordialement
23/10/2006, 15h56
sky_striker

Voila comme promi voici le résultat de mes investigations :

Sur les 9.40 min que necessite la dépagination de 1000 éléments j'ai relevé qu'environ 1,10 min est consacré à la génération STRUTS elle même ce qui est qd même assez performant.

Le reste est reparti entre le teléchargement des 6 Mo que représente la page et à l'interprétation du code HTML généré. Enfin le code javascript est tout simplement inexploitable même sur ma machine qui est un récent P4 avec 1024 Mo de RAM.

Voila je reste ouvert à toute suggestion et remerci tous ceux qui me liront et participeront à ce sujet

Cordialement
23/10/2006, 16h35
woodwai

Personnelement, je ne pense pas qu'un affichage de 1000 éléments dans un context web ou intranet corresponde réelement à quelque chose, en effet, personne ne peut lire tout ça d'un coup.

Je pense que la seule solution soit la pagination. Tu peut regarder du coté de la tyaglib displayTag qui permet de faire de la pagination tout seule, en plus tu peut ajouter trés facilement une couche ajax à tout ça pour faire une pagination qui recharge ta page en ajax ce qui permet de limiter le trafic réseaux.

display tag : http://displaytag.sourceforge.net/11/
ajax framework with display tag : http://ajaxtags.sourceforge.net/
24/10/2006, 09h38
sky_striker

Citation:

Envoyé par woodwai

Personnelement, je ne pense pas qu'un affichage de 1000 éléments dans un context web ou intranet corresponde réelement à quelque chose, en effet, personne ne peut lire tout ça d'un coup.

Je pense que la seule solution soit la pagination. Tu peut regarder du coté de la tyaglib displayTag qui permet de faire de la pagination tout seule, en plus tu peut ajouter trés facilement une couche ajax à tout ça pour faire une pagination qui recharge ta page en ajax ce qui permet de limiter le trafic réseaux.

display tag : http://displaytag.sourceforge.net/11/
ajax framework with display tag : http://ajaxtags.sourceforge.net/

Salut et merci de ta réponse

Je suis d'accord avec toi sur le fait que l'affichage de 1000 éléments ne sert à rien mais dans mon cas ce ne n'est pas du contenu "a lire" à proprement parlé. Quoi qu'il en soit cela aurait pu il est vrai être réalisé de maniére plus efficasse mais bon c'est ça qui a été vendu au client et il a l'air d'y tenir.

J'ai également regardé les liens que tu m'as donné et nous avons déjà notre propre moteur de pagination le probléme vient du fait que 'l'utilisateur puisse dépaginer sa liste pour consulter les élément d'un seul coup.

J'ai orienté mes recherches différement et j'ai fait quelques mesure sur FireFox j'ai constaté que les performances javascript sont quelque chose comme dix fois meilleures. A titre d'exemple sous IE 6.0 la selection d'un élément par checkbox prend environ 1,40 min contre 1 seconde pour firefox.

Même si le gain n'est pas aussi significatif j'ai également constaté une différences dans l'interprétation du code HTML.

Quelqu'un peut il m'éclairer sur d'éventuelles options ou optimisation qui pourrait pénaliser à ce point l'éxécution sous IE 6.0 ?

Tout idée ou commentaire est toujour le bienvenu

Cordialement
24/10/2006, 10h44
petitpasdelune

Tuer le client ? :aie:
Plus sérieusement, cela donne quoi avec IE7 ?
Ils ont fait des progrès. Meme si il y a encore des problèmes
avec le plugin SVG d'Adobe et 2 ou 3 petits trucs.

PPDL.

(je sais je n'ai pas répondu à la question mais bon....)
24/10/2006, 13h48
yolepro

Citation:

Envoyé par sky_striker

Les problèmes sont diverses :
- La page HTML généré ne l'est pas en moins de 9 minutes en local et 5 sur mon serveur ce qui bien évidement trop long
- La taille de la page généré approche les 6.5 Mo ce qui rend le parsing trés lent

Le problème principal vient tout simplement d'ici.
Une source qui pese 6Mo pour une page HTML c'est totalement inexploitable.

Struts et autre n'y sont pour rien.

Malgres cela essayons d'optimiser :

Citation:

Envoyé par sky_striker

- Même si le nombre d'éléments de la liste ne parait pas excessivement grand les 1000 éléments contiennent eux aussi des sous éléments ce qui donne en struts deux boucle imbriqués sur des objets "complexes".

Qu'entends tu par la? Ne peux tu pas - pour cette liste en particulier - faire un objet optimisé (avec juste les champs nécessaire).
Dans tous les cas, 1000 elements même s'ils sont imbriqués ne doivent pas poser trop de problème pour le serveur (a part si tu y stoques un texte de 4000 char par objet bien sur ;)).

Citation:

Envoyé par sky_striker

- Enfin dernier point il y a des actions qui sont gérées en javascript sur les éléments (chaque liste de sous éléments pouvant être affiché/masqué selon les besoins) ce qui génére encore plus de texte sur la page :-(

Je pense plutot que le problème principal vient de la.
Le javascript est totalement dépassé quand il sagit de manipuler des tableaux contenant 1000 élément raison de plus si ce sont des objet complexes.

Je pense que si tu veux optimiser reellement, il faut changer de gestion d'affichage (tri, pagination,... via le serveur en utilisant struts layout ou display tag comme dit au dessus).