Primefaces remotecommand – exécuter un traitement long tout en préservant les performances

Nous avons tous été confrontés à une expérience utilisateur désastreuse due à un problème de performance sur une page qui met en jeu des traitements complexes.

Une solution consiste à afficher immédiatement une partie des informations et à compléter les informations manquantes de la page quelques secondes plus tard lorsque toutes les données ont été collectées.

Pour résoudre cette difficulté vous pouvez utiliser le composant remoteCommand qui permet d’invoquer une méthode d’un bean.

<p:remoteCommand id="myRemoteCommand" name="myRemoteCommand" async="false" actionListener="#{bean.heavyWork}"
 update="widget" process="@this" autoRun="true"/>

Dans cet exemple la méthode bean.heavyWork() est invoquée immédiatement après le chargement de la page (autoRun= »true »). A la fin de l’exécution de la méthode l’élément « widget » de la page est mis à jour.

La zone de la page qui est mise à jour ne doit pas inclure le composant remoteCommand et le composant doit être intégré dans un formulaire.

Si vous déclenchez le composant remoteCommand à partir d’une fonction javascript vous pouvez également passer des paramètres à la commande.

$(document).ready(function() { 
 myRemoteCommand( [ { name: 'latitude', value: latitude }, { name: 'longitude', value: longitude } ] );
});

Dans ce cas on peut récupérer les paramètres dans la méthode bean.heavyWork en utilisant la méthode

FacesContext.getCurrentInstance().getExternalContext().getRequestParameterMap()

Dans cet exemple nous avons utilisé l’attribut async= »false » mais on pourrait parfaitement rendre le traitement asynchrone (avec async= »true ») et utiliser la commande « poll » pour rafraîchir la page avec les données issues du traitement.

http://www.jperf.com

 

 

 

Publié dans Primefaces | Tagué , | Laisser un commentaire

Primefaces – comment arrêter le polling

Le composant « poll » de Primefaces permet de lancer des requêtes périodiquement (selon un intervalle de temps exprimé en seconde). Il est possible d’interrompre cette action en fonction de l’état du serveur.

Imaginer par exemple que vous implémentiez un traitement long et que vous souhaitiez que certains éléments de la page soient rafraîchis, avec les informations issues de ce traitement, dès que l’action est terminée. Par ce que vous êtes soucieux des performances de l’application et de l’expérience utilisateur vous avez utilisé une commande asynchrone pour déclencher ce traitement.

Depuis la version 3 de Primefaces, la fin de l’action de « polling » est très simple à implémenter.

 <p:poll interval="5" timeout="4000"
 listener="#{bean.listen}"
 update="widget" autoStart="true" stop="#{bean.disable}" />

Dans cet exemple une requête est exécutée toutes les 5 secondes. La requête est considérée comme terminée après 4 secondes (timeout exprimé en ms). La méthode listen du bean permet de gérer le changement d’état du serveur et d’arrêter l’action de polling en positionnant la valeur de l’attribut disable du bean à true.

private boolean disable= false;
public void listen() {
 if(condition) {
 disable= true;
 }

Et c’est tout… Primefaces gère l’arrêt du « polling » automatiquement dès que l’attribut « stop » prend la valeur true.

Attention tout de même à prévoir de limiter le nombre de tentative de « polling » car si la condition d’arrêt n’est jamais remplie vous risqueriez de compromettre inutilement les performances de votre application.

http://www.jperf.com

Publié dans Primefaces | Tagué , | Laisser un commentaire

Modifier les paramètres de la JVM au runtime

Peut être avez vous eu besoin au cours de votre expérience de modifier les paramètres de lancement d’une JVM pour activer par exemple les traces du garbage collector?

Sachez qu’il existe un moyen de réaliser cette opération sans devoir arrêter / redémarrer le processus java.

La commande jinfo  affiche la configuration java d’un processus. Les informations éditées comprennent les propriétés système ainsi que les paramètres de lancement de la machine virtuelle.

Pour mémo voici, ci dessous, l’aide en ligne de la commande jinfo.

Usage:
jinfo [option] <pid> (to connect to running process)
jinfo [option] <executable <core> (to connect to a core file)
jinfo [option] [server_id@]<remote server IP or hostname> (to connect to remote debug server)

where <option> is one of:
-flag <name> to print the value of the named VM flag
-flag [+|-]<name> to enable or disable the named VM flag
-flag <name>=<value> to set the named VM flag to the given value
-flags to print VM flags
-sysprops to print Java system properties
<no option> to print both of the above
-h | -help to print this help message

Savez vous que vous pouvez utiliser cette commande pour modifier dynamiquement les paramètres de la JVM? Effectivement en utilisant l’option « flag » vous pouvez activer ou désactiver un paramètre.

Par exemple:
La commande jps nous donne les ids des processus java présents sur la machine.
jps
3572 Jps
15484 Bootstrap
14744 org.eclipse.equinox.launcher_1.3.0.v20120522-1813.jar

Si vous souhaitez activer les traces du garbage collector vous pouvez utiliser la commande suivante:

jinfo -flag +PrintGC 12278
jinfo -flag +PrintGCDetails 12278
permet d’afficher les traces détaillées sous la forme
[GC [PSYoungGen: 429689K->46346K(454656K)] 473190K->106420K(804352K), 0.0534327 secs] [Times: user=0.17 sys=0.00, real=0.05 secs]

http://www.jperf.com

Publié dans tech notes | Tagué , , | Laisser un commentaire

Utilisation du SingleThreadModel dans les servlets

Lorsque vous concevez un Servlet vous devez prendre en considération que ce composant sera probablement invoqué dans un contexte multi-utilisateur qui introduit une concurrence d’accès aux ressources.
Il est inévitable que le composant soit sollicité par plusieurs utilisateurs simultanément. Il est donc nécessaire que votre code soit protégé contre ce type de mode d’accès.

Une instance d’une classe qui implémente l’interface SingleThreadModel est protégée contre l’invocation simultanée par plusieurs threads. Le moteur de servlet garantit qu’il n’y aura qu’une seule requête traitée par la méthode service() à la fois pour chaque instance du Servlet.
Cette exigence peut être résolue par le serveur d’application soit en rendant séquentiel les invocations de méthode soit en maintenant un pool d’instances du Servlet.

Dans le cas du pool de Servlet, plusieurs instances de Servlet sont utilisées pour servir des requêtes simultanées, chacune étant traitée par un thread et une instance dédiés.

Par exemple pour optimiser le traitement de Servlet implémentant cette interface WebLogic implémente, depuis plusieurs versions, un mécanisme de pool que l’on peut dimensionner avec le paramètre SingleThreaded Servlet Pool Size.
Attention toutefois car la valeur par défaut de ce paramètre est fixé à 5. Cela signifie qu’il ne peut pas y avoir plus de 5 requêtes traitées simultanément par un servlet implémentant cette interface.

Attention car cette interface est dépréciée dans les dernières versions de la spécification JEE et ce type d’implémentation ne protège pas contre l’accès concurrent aux ressources partagées.

Publié dans tech notes, Uncategorized | Laisser un commentaire

Brown Bag Lunch

L’idée du site http://www.brownbaglunch.fr/ est originale et très séduisante. Elle consiste à favoriser les échanges dans l’entreprise en invitant un expert d’un domaine à discuter autour d’un déjeuner sur un thème particulier. Le slogan est simple et très évocateur « les meilleurs experts pour un midi chez vous, gratuitement ».

Pour cela il vous suffit de choisir parmi la liste des baggers, l’expert qui pourra vous parler du sujet qui vous convient. Vous prenez en charge l’organisation de la rencontre (salle, repas) et définissez avec le bagger le sujet précis que vous souhaitez aborder.

Si vous souhaitez devenir un bagger il vous suffit de suivre les instructions fournies ici https://github.com/nrichand/BrownBagLunch.

Quant à moi, je vous propose de nous rencontrer sur Bordeaux pour parler ensemble de la performance des applications (http://www.brownbaglunch.fr/baggers.html#Bordeaux).

http://www.jperf.com

Publié dans Divers | Laisser un commentaire

Performance – la task force « performance » est une vraie fausse bonne idée.

Monter une équipe pluri-disciplinaire pour travailler sur une problématique de performance peut être vue par la hiérarchie d’un projet comme une action rassurante mais elle peut s’avérer rapidement très décevante.

Les responsables du projet vont voir dans cette task force une organization permettant de rapidement débusquer les problèmes de performance et les solutionner tout aussi rapidement puisque toutes les compétences sont mobilisées.

Or la réalité du terrain en matière d’audit de performance est toute autre.

Tout d’abord précisons ce que nous entendons par task force?
La task force dont nous parlons est une équipe pluri-disciplinaire qui est constituée dans notre cas pour résoudre des problèmes de performance d’une application. Cette task force est créée à l’initiative d’un manager dans le but de faire travailler simultanément plusieurs ressources à la résolution de problèmes. Les motivations principales sont de réunir toutes les compétences autour de la table pour faciliter le diagnostic d’une défaillance et sa correction. En effet l’activité d’audit de performance est multi disciplinaire et il n’est pas simple pour un manager de recruter le ‘mouton à 5 pattes’ connaissant le réseau, le système, les socles applicatifs, les moyens de supervision, la méthodologie de test, les outils de test, le langage de développement, etc.
Donc réunir toutes les compétences semblent être une démarche intéressante et productive.

La mise en place de la task force dans laquelle tous les intervenants seraient mobilisés en même temps voire même regroupés physiquement dans un même lieu, est réellement une vraie fausse bonne idée.

Mon premier argument repose sur la difficulté à cadrer l’activité dans cette équipe pluri-disciplinaire.

En effet l’audit de performance est une activité qui doit être menée avec méthodologie. Or faire travailler ensemble tout ce petit monde d’experts, qui auront probablement un égo surdimentionné, peu devenir un vrai challenge. Il faut d’abord qu’ils partagent une vision commune de l’architecture, et des objectifs du chantier. Chacun étant persuadé qu’il détient la vision idéale, la solution au problème ou que le problème vient forcément d’une autre couche de l’architecture que celle sur laquelle il travaille communément.

Cette task force est l’hydre de Lerne. Chacun des membres tirant vers une issue mais chacun oubliant également l’objectif premier de cette task force.

Le manager peut prendre la tête de ce petit groupe pour essayer de le coordonner mais il va lui manquer la méthodologie de travail et peut être une base technique lui permettant par exemple d’organiser les actions de 2 techniciens ayant un point de vue radicalement opposé sur une problématique.

Ce n’est pas facile à faire fonctionner mais l’équipe peut tout de même être dirigée. Reste tout de meme à trouver une approche méthodologique efficace de l’activité?

Mon second argument repose sur la nature même de l’activité.
En effet, l’audit de performance est une activité incrémentale impliquant de multiples actions très chronophages. Selon la maturité du chantier, il peut être nécessaire de définir des objectifs « métiers », des scénarios d’utilisation du système, d’identifier des volumétries de données et préparer un environnement de test, de scénariser les cas d’utilisation, d’organiser la supervision des systèmes et la collecte des métriques, puis d’analyser les résultats des tests, diagnostiquer les dysfonctionnements, modifier éventuellement le code de l’application, et réitérer la démarche pour s’assurer de la pertinence des ajustements … In fine, la plupart du temps, il est généralement demandé d’élaborer un rapport permettant de capitaliser les résultats du chantier et animer des scéances de présentation des résultats aux managers et aux techniciens du projet.

Et c’est bien là qu’apparait une autre difficulté. Regrouper des experts qui attendent qu’une action soit à réaliser dans leur domaine de compétence.

Vous aurez compris que pour conserver la motivation de cette équipe pendant toute la durée du chantier cela va relever également du challenge.

Non décidément je n’y crois pas!

A moins que …

Et si cette activité d’audit de performance était menée par un expert de la performance qui aurait le recul nécessaire pour mettre en place la méthodologie liée à cette activité. Idéalement cette personne devrait posséder une autonomie sur les outils de test, et un domaine d’expertise complémentaire ainsi qu’une connaissance générale sur les autres sujets. Il pourrait être ainsi le leader sur l’activité. Il aurait une autonomie suffisante pour gérer le chantier au jour le jour en communiquant auprès du manager l’avancement de l’activité. Donc plus de problèmes de gestion et de coordination de l’équipe!
Et s’il savait identifier des problèmes potentiels, il pourrait être accompagné par un expert pour établir un diagnostic plus précis des dysfonctionnements relatifs au domaine de compétence du spécialiste. Donc plus de problèmes d’organisation de l’activité et de motivation de l’équipe.
Le role du manager consiste, dans ce cas, à mobiliser une équipe sur le chantier de performance en précisant l’organisation du chantier et la responsabilité de chaque intervenant.

Comme vous l’aurez constaté au travers du titre volontairement provocateur, la task force « performance » telle qu’elle est décrite ci dessus semble être une bonne idée mais n’en est vraissemblablement pas une.

Et vous, comment vous êtes vous organisés pour résoudre vos problèmes de performance?

http://www.jperf.com

Autres articles sur le sujet:

http://apmblog.compuware.com/2013/10/30/10-questions-to-avoid-a-classical-business-war-room-scenario/

 

Publié dans performance | 2 commentaires

Maven, m2e, Eclipse WTP

J’ai récemment été confronté à une problèmatique d’intégration entre différents outils de développement java : maven, m2e (plugin maven pour eclipse) et WTP (Web Tools Platform).

Mon projet qui avait été créé à l’origine avec la commande mvn eclipse:eclipse me posait des problèmes lorsque j’ajoutais des librairies dans les dépendances  maven (POM). L’un des symptomes était l’affichage de messages d’erreur lorsque j’essayais de déployer le projet sur un serveur tomcat démarré localement (dans eclipse): le serveur ne reconnaissait pas les classes appartenant à ces nouvelles librairies.

Ces problèmes étaient principalement lies à une incomptatibilité entre la commande maven utilisée pour créer le projet et l’utilisation du plugin m2e. Pour contourner ce problème, j’ai du supprimer le projet (sans supprimer le contenu physique), supprimer les fichiers .classpath/.project(et ./settings), et importer le projet en tant que projet maven.

A ce stade le projet est recréé parfaitement mais ne peut pas être déployé sur un serveur local. Pour cela, il faut lui définir une facet « Dynamic web module » au travert des propriétés du projet. Cette manipulation crée de nouveaux repertoires dont le « Web-content » qui doit contenir par défaut l’ensemble des elements déployables. Or cette arborescence ne correspondait pas à la structure de mon projet.

Pour solutionner cette dernière difficulté, je me suis inspiré de l’article http://www.mkyong.com/maven/how-do-use-maven-to-create-a-dynamic-web-project-in-eclipse/ . J’ai notamment modifié le contenu du fichier org.eclipse.wst.common.component (du repertoire .settings) pour faire pointer les différents elements vers l’arborescence de mon projet.

Il y a surement d’autres moyens de réaliser ce type d’action ou même de les éviter.
Mais je n’ai trouvé que ces contournements pour solutionner mon problème.

L’idéal étant probablement de créer un projet web dynamic et de lui ajouter une nature maven et non l’inverse.

http://www.jperf.com

 

Publié dans tech notes | Laisser un commentaire