Réglage JSF

Question

Vous rencontrez un problème où JSF est en train de remplir nos sessions. Nous avons eu un crash système l'autre jour. Envoyé le tas à IBM pour vérification et constaté que nous avions des sessions de 50 millions de personnes. Ils ont trouvé des composants JSF dans la session et certains très volumineux.

Alors, y a-t-il un réglage qui peut être fait? Éléments de configuration à regarder? Ou autre direction.

Notre système est construit à l'aide de JSF et de Spring pour la couche de présentation. Le back-end est composé d'EJB, de Spring et d'Hibernate fonctionnant tous sur WebSphere 6.1.

Answer 1

JSF est une technologie utile, mais vous pouvez certainement vous y accrocher.

Cela ressemble à cela, soit vous augmentez la taille de l'état d'affichage (en définissant des valeurs élevées sur les composants), soit vous perdez des références à des composants dans un autre état de session (ce qui serait mauvais). Un autre coupable potentiel serait une vue excessivement large (j'ai vu la facilité avec laquelle les utilisateurs peuvent construire des arborescences d'interface utilisateur aboutissent à de très grands graphiques de contrôle avec des tableaux de données partout). Je sais qu'IBM fournit des contrôles de texte enrichi et de feuille de calcul. Je ne peux pas dire quel effet cela aura sur la taille de l'état.

La solution la plus simple est de vérifier les beans gérés configurés pour l'étendue de la session dans faces-config.xml .

JSF enregistre deux éléments entre les demandes:

• la vue (tous les contrôles de la page)
• l'état d'affichage (l'état des contrôles)

Ils sont séparés car certains contrôles, tels que les enfants d'un tableau de données, peuvent avoir plusieurs états (un pour chaque ligne). State peut être enregistré dans un champ caché du formulaire (qui, s'il n'est pas chiffré, peut constituer un risque important pour la sécurité) ou dans la session. Afin de gérer plusieurs fenêtres de navigateur partageant la même session (et, dans certaines implémentations, la prise en charge du bouton Précédent), plusieurs vues sont stockées.

• Il devrait exister une option de configuration permettant de définir le nombre d'états d'affichage que l'application maintiendra dans la session pour un utilisateur donné à un moment donné.
• Vous pouvez mesurer la taille de l'état d'affichage en fournissant un StateManager qui mesure la taille de la vue / de l’état enregistré (configurez un StateManager dans faces-config.xml avec un constructeur public qui prend un StateManager - voir Spéc. JSF Pour obtenir plus de détails sur les PDF JSF , l'état est sérialisable et vous pouvez vérifier sa taille en le vidant dans un flux) .

La plupart des applications JSF construites par l'IDE ont des beans de sauvegarde. Il serait possible, via l’étendue du bean session, de conserver l’état plus longtemps que vous le souhaitez, ce qui alourdirait la session. Puisqu'il y a généralement un bean de support par page, plus le nombre de pages est élevé, plus le problème sera grave. Vérifiez votre faces-config.xml pour voir s’il s’agit d’une source potentielle de problèmes.

Vous pouvez également configurer un HttpSessionAttributeListener dans votre web.xml . Vous pouvez obtenir un suivi de pile pour aider à identifier les problèmes dans votre application.

Answer 2

C'est le deuxième système dont j'ai entendu parler qui est mort à cause de JSF et de la création excessive d'objets. L'autre utilisait également Spring et Hibernate à l'arrière. Le profilage avec OptimizeIt a montré que la réponse du back-end était de l'ordre de quelques millisecondes pour toutes les demandes, mais vous pouviez chronométrer le rendu du navigateur avec un chronomètre, car cela prenait tellement de temps - 30 secondes, voire plusieurs minutes. La mémoire consommée par le client était ridicule.

Je n'étais qu'un observateur et non un membre de cette équipe de projet. Je vais devoir demander si le problème a déjà été résolu et, le cas échéant, quelle aurait été la solution.

Mais si deux points marquent une tendance, je dirais que JSF pourrait être fatalement défectueux. Personnellement, je m'en tiens complètement à l'écart.

Pourquoi ne pas essayer un frontal Web Spring et voir si cela vous aide? Si vous suivez l'idiome Spring, le remplacement de JSF par des JSP et des contrôleurs Spring basés sur JSTL devrait être relativement simple.

Answer 3

Je travaillais sur un projet JSF et j'ai constaté que nous avions un bogue qui ajoutait plusieurs éléments JSF h: form. Il en résulte une copie de l'intégralité de viewstate incluse dans chaque formulaire. Réduire à un formulaire par page réduit les pages de ~ 2M à ~ 300K.

Answer 4

Vous rencontrez peut-être des problèmes avec de nombreux beans de sauvegarde en tant qu'étendue de session.

Vous pouvez essayer d’explorer MyFaces Orchestra . Il s'agit d'une bibliothèque qui fournit une étendue de conversation. Ainsi, lorsqu'un utilisateur a terminé avec un ensemble particulier de beans, il sera supprimé de la session.

Je comprends que Spring WebFlow possède des fonctionnalités similaires, mais je ne l'ai pas encore vraiment étudié!

Answer 5

JSF stocke les vues en session pour prendre en charge son architecture à composants riches. (besoin de conserver son état d'affichage) et peut remplir le tas s'il n'est pas utilisé correctement. Si vous n’avez pas de gros flux de travail, utilisez toujours un petit nombre de points de vue par session. Évitez également de garder les haricots de sauvegarde en session autant que possible. Utilisez la balise personnalisée pour créer l'objet de données uniquement pour le prochain cycle de demande. Nous pouvons également utiliser Spring Web Flow avec JSF, qui introduit la portée de vue et la portée de flux si nous avons de longs flux de travail dans l’application pour réduire le nombre de vues configurées dans la session. JSF peut être utilisé pour créer facilement une interface utilisateur riche, ce qui permet de créer une application Web similaire à une application de bureau. Attribuer un tas spécifique au framework JSF pour faire son travail. Mais utilisez efficacement la mémoire côté application et assurez-vous qu'il n'y a aucune fuite de mémoire. Toutes les fuites de mémoire doivent être examinées et corrigées au cours du développement même. Utilisez toujours un profileur pour rechercher les fuites de mémoire et les goulots d'étranglement des performances existants dans l'application.

Mat.

Answer 6

Si vous utilisez MyFaces < 1.1.6 il y a une énorme fuite de mémoire dans la façon dont il met en cache les anciennes vues sérialisées dans la session, ne les laissant jamais libérées afin qu'elles puissent être récupérées. J'ai eu un sérieux problème avec cela et j'ai également eu des sessions de 50 Mo. Une mise à niveau rapide de MyFaces a corrigé le problème sans aucun problème.

Answer 7

Configurez session persistense en base de données et il utilisera l'algorithme le moins utilisé pour repousser en mémoire les sessions les moins utilisées. Il est très performant (lorsqu'il est configuré correctement) et vous aidera concrètement et rapidement.

Answer 8

Un peu d’un vieux sujet, mais j’ai découvert cela récemment. Souvent, la vue et l'état de la vue sont stockés (comme indiqué précédemment) et remplissent la session pour permettre au bouton Précédent de fonctionner. Il existe des paramètres pour trier cela dans vos descripteurs de déploiement (web.xml) qui doivent être définis.

Plusieurs instances de certaines bibliothèques peuvent nécessiter plusieurs paramètres, par exemple lors de l'utilisation de MyFaces et de JSF RI. Par défaut, ils peuvent être réglés sur des valeurs assez élevées (20 et 16, je crois, respectivement). Cela signifie que vous pouvez utiliser 20 fois l’espace qui vous convient pour (des parties?) De la session.

Answer 9

Conseils de réglage JSF pour les environnements de production:
 - L'utilisation des images, des ressources CSS et JavaScript doit être effectuée à l'aide de balises HTML standard (img,link,script) et non côté serveur. Veillez également à définir #{request.contextPath} avant l'URL pour éviter les problèmes de chemins relatifs.
 - Cache les sections statiques de la page (menu,header,footer) avec omnifaces cache
 - Définir refresh-period variable sur -1
 - définir project-stage sur Production
 - Vérifiez vos filtres de code, le cas échéant

Consultez également mon article " serveur Java. Visages dans les applications réelles & Quot; sur DZone, il vous donnera une image complète de JSF dans les environnements de développement, de test et de production.