Publié le 29 novembre 2008 par Thomas Recloux
Olivier m’a envoyé hier un email pour m’annoncer la sortie de son nouveau projet OpenSource : Appspy.
Appspy offre une solution pour le suivi de vos applications Java coté serveur en production, vous pourrez ainsi consolider toutes sortes de données issues des différentes instances de vos applications et par exemple savoir quelles URLs sont sollicitées, quelles URLs sont lentes ou encore comparer les temps de réponse entre deux versions.
Les applications intègrent un module client qui collecte les données et les fournit au serveur qui permet de les visualiser sous formes de rapports paramétrables. Le tout est disponible sous la licence Apache 2.0 qui est « business friendly ».
Je ne vais pas tarder à essayer cet outil sur un de mes projets, je vous en dirai plus à ce moment la. Ayant eu l’occasion d’utiliser un ancien produit de la même gamme écrit par Olivier, je suis assez impatient 
Tags: java, performances, prod | Aucun commentaire »
Publié le 29 octobre 2008 par Thomas Recloux
A plusieurs occasions, j’ai eu l’occasion de conseiller l’utilisation de Spring JMS car cette API simplifie énormément la manipulation de l’API JMS qui il faut l’avouer n’est vraiment intuitive.
En effet l’API JMS nécessite de manipuler 6 objets (QueueConnectionFactory, QueueConnection, QueueSession, Queue, MessageProducer, TextMessage) pour simplement envoyer un message texte !
Avant de pouvoir utiliser l’api Spring JMS, il faut configurer une ConnectionFactory (Exemple avec Active MQ) :
<bean name="activeMqConnectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
<property name="brokerURL" value="tcp://theactivemqserver:61616" />
</bean>
Ensuite, il faut récupérer un objet JmsTemplate dans lequel la ConnectionFactory aura été injectée.
Enfin, l’envoi d’un message peut se faire de différentes manières mais un simple appel de la méthode convertAndSend pourra suffir.
Il se trouve que par défaut le JmsTemplate peut limiter les performances des applications car il entraine la création des objets Connection, Session et MessageProducer pour chaque envoi.
La solution peut se trouver du coté du provider JMS qui comme ActiveMQ peut proposer une ConnectionFactory adaptée en gérant un pool d’objets Connection, Session et MessageProducer.
La solution peut aussi venir d’un objet fourni par Spring depuis la V2.5.3 : CachingConnectionFactory cette ConnectionFactory peut encapsuler n’importe quelle autre ConnectionFactory et mettre en place le cache de Connection, Session et MessageProducer.
Dans mon cas, l’utilisation de la CachingConnectionFactory a résolu nos problèmes. Un profiling de l’application avait montré que nos Threads passait leur temps à ouvrir des Session JMS.
Tags: java, jms, performances, spring | Aucun commentaire »
Publié le 8 mars 2008 par Thomas Recloux
Je prépare actuellement une formation au profiling avec JProfiler, j’ai choisi de travailler à partir de l’application Jpetstore, application exemple fournie avec le framework spring. Le tout étant déployé dans un conteneur Tomcat 5.5.25
J’ai inséré dans cette application quelques problèmes à corriger par les stagiaires et notamment une fuite mémoire, j’ai eu la surprise en contrôlant l’efficacité de ma fuite de constater que d’autres fuites étaient présentes.
En effet, certains objets du domaine restent présents dans la mémoire de la JVM et ne sont pas récupérés par le garbage collector . L’application utilise la librairie de tag (taglib) JSTL via l’implémentation de Jakarta, c’est un des tags de cette librairie, le tag forEach qui garde des références vers les objets de la liste parcourue.
En creusant un peu plus, le problème est identifié depuis longtemps dans au sein du projet taglib et au sein du projet tomcat.
En fait le composant taglib présente une méthode qui libère ses données, mais elle n’est pas appelée par le moteur de JSP de Tomcat (Jasper), les deux équipes semblent se renvoyer la balle en expliquant qu’ils implémentent bien leurs spécifications respectives. Le problème est censé disparaître en désactivant le pooling des tags dans tomcat, mais je n’ai pas pu constater d’amélioration.
Tout cela est bien décevant de la part de ces deux projets, je vais essayer de mesurer prochainement le comportement de la fuite dans le temps, est ce que le nombre références augmente ou au contraire plafonne ?.
Tags: java, jsp, performances | Aucun commentaire »
Publié le 26 février 2008 par Thomas Recloux
Au grès des missions et des projets, j’ai plusieurs fois eu l’occasion d’optimiser des applications Java / J2EE.
Pour optimiser une application, il faut détecter les éléments consommateurs à l’aide d’un profiler. Le profiler est un logiciel qui se connecte à la machine virtuelle et récupère des informations sur les enchainements de méthodes et les allocations d’objets.
Cela permet de détecter quelles méthodes prennent du temps soit en consommant de la CPU soit en attendant un traitement distant (requête SQL ou LDAP, Appel d’un EJB ou d’un Web Service, ….).
Les profilers permettent d’avoir une vue arborescente des piles d’appel, par exemple quelles méthodes sont déclenchées par une requête HTTP ou quel composant consomme le plus de temps sur cette requête
Pour alimenter le profiler en données à analyser, il faut faire travailler les applications que l’on veut optimiser. L’idéal est de définir des scénarios d’utilisation de l’application à partir de statistiques de production, afin de reproduire les actions les plus utilisées.
Pour automatiser ces scénarios, des outils comme OpenSTA, The Grinder ou JMeter sont très adaptés.
Une fois le profiler mis en place et les scénarios automatisés, je fonctionne de manière itérative en effectuant les actions suivantes :
- Lancement du tir en utilisant les scénarios automatisés
- Analyse des résultats
- Correction / tests unitaires / déploiement
La présence de tests unitaires et de tests fonctionnels permet d’accélérer la phase de corrections et de déployer plus rapidement les corrections en production en s’assurant de la non régression.
Je pense que des interventions de ce type sont nécessaires sur toutes les applications ou groupes d’applications dont le niveau de performance est important et sont obligatoires quand on constate que l’infrastructure de production est trop sollicitée.
Les profilers phares du marché sont :
Tags: java, performances | 2 commentaires »
