Problème de chargement des fontes « Failed to decode downloaded font »

Voici un lien vers un article permettant de résoudre cette problématique sur des projets utilisant maven

http://shortfastgood.blogspot.fr/2015/08/maven-build-and-webfonts.html

Publié dans tech notes, Uncategorized | Laisser un commentaire

Font Loading Techniques

Cette page est simplement un signet vers un site exposant les techniques d’amélioration des performances lors du chargement des fontes.

http://romain-menard.fr/cours/web/mooc/premiere-etape-changer-le-fond-de-page/

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

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