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 »
Publié le 22 février 2008 par Thomas Recloux
La plupart des SI ont un passé et disposent de systèmes anciens dits « legacy », ces systèmes hébergent encore de nombreuses applications et leur remplacement ne peut pas se faire du jour au lendemain.
Il est donc important de pouvoir valoriser ces systèmes et de les intégrer dans des architectures à base de service dites SOA.
Pour les systèmes AS/400, OS/400, i5/OS, iseries ou System i (rayez les mentions inutiles), voici les mécanismes que j’ai mis en oeuvre:
- Exposition de services de l’AS/400
IBM publie en OpenSource une librairie nommée JT400 qui permet de se connecter à l’AS400 et entre autre de faire du RPC en lançant les programmes à distance. La connexion se fait en TCP/IP et cela fonctionne avec des programmes écrits en COBOL, RPG et RPG ILE, avec des scripts CL et probablement dans d’autres langages.
La javadoc de la classe ProgramCall contient un bon exemple d’utilisation.
Une fois le service interfacé en Java, il est exposé vers le monde « ouvert » et peux donc être ré exposé sous toutes les formes possibles : WebService SOAP, Resource REST, EJB, …..
- Consommer un service depuis l’AS/400
IBM met à disposition une boite à outil qui permet de consommer des WebServices SOAP depuis des programmes C, RPG ou COBOL qui tournent sur l’AS/400.Cette boite à outil est en fait un portage de la librairie Axis C vers l’AS/400 ce qui est à mon avis un bon signe de maturité.
Cet article explique la méthode à utiliser. Voici quelques remarques suite à l’utilisation que j’en ai faite.
- Les chaines de caractères sont de type « xsd_string », ils faut les passer au stub SOAP par adresse (%addr) et non par valeur.
- Ne pas oublier de tronquer les chaînes de caractères à la bonne longueur et d’y ajouter un zéro binaire (X’00′) que ce soit pour l’URL du WebService ou pour ses paramètres
Le RedBook nommé « Building SOA-based Solutions for IBM System i Platform » documente les différentes manières d’intégrer un AS/400 dans une architecture orientée service.
Tags: as400, soa | Aucun commentaire »
Publié le 15 février 2008 par Thomas Recloux
Je n’ai jamais eu l’occasion de participer à des projets qui utilisent une de ces deux bases autrement que pour des tests rapides ou des outils utilisés par l’équipe (Mantis, Cacti, ce blog, … ), les clients pour lesquels j’ai travaillé utilisent les bases des grands acteurs du marché, essentiellement Oracle et DB2, éventuellement dans leurs versions gratuites pour des applications moins critiques et des volumes réduits.
La lecture de cette documentation de PostgreSQL détaillant les différences entre PostgreSQL et MySQL est très intéressante pour en savoir un peu plus sur ces deux bases. PostgreSQL me semble plus proche des grosses bases de données commerciales alors que MySQL me donne une image plus « lightweight ». L’article référence des benchmarks effectués par SUN, cité comme acteur indépendant ce qui est assez amusant car depuis Sun a acheté MySQL. L’article indique que les résultats des deux concurrents sont équivalents et un peu inférieurs à ceux d’Oracle qui est cité étant le SGBD le plus performant :
« le meilleur des produits commerciaux en terme d’efficacité des performances »
L’article indique que les performances par dollar sont tout de même à l’avantage des bases OpenSource, en évitant de s’attarder sur le coût du support. Les grosses entreprises ne veulent souvent pas se passer d’un support commercial pour les éléments d’infrastructure et dans ce domaine la facturation au CPU voir au coeur reste souvent la règle.
(via scub)
Tags: mysql, postgresql, sgbd | Aucun commentaire »
Publié le 12 février 2008 par Thomas Recloux
Xebia a lancé une série de quizz autour de Java / J2EE, les 50 premiers au classement seront conviés à un tournoi de poker qui va permettre de gagner des lots intéressants.
Je trouve cette initiale originale et très sympathique, même si le but n’est sûrement pas philanthropique. J’imagine que cette opération est bonne en terme d’image et de recrutement.
A vos questionnaires et qui sait, rendez vous autour d’une table de poker ?
Tags: java | Aucun commentaire »
Publié le 12 février 2008 par Thomas Recloux
Dans des articles précédents, je découvrais les fonctionnalité de Jetty 6 et de Tomcat 6 pour déconnecter les requêtes HTTP de leur Thread de traitement, ce qui permet de mettre en place de manière efficace du « poll » longue durée depuis un client AJAX, ce qui revient presque a pouvoir faire du « push » du serveur vers le client.
La cinématique est la suivante :
- Le client initie une connexion HTTP vers le serveur, en tache de fond à l’aide du composant XmlHttpRequest ou d’une iFrame cachée
- Le serveur reçoit la requête et n’envoie une réponse au client que quand un événement est à présenter.
- Si au bout de quelques dizaines de secondes le serveur n’a pas d’évènements à pousser vers le client, il renvoie tout de même une réponse qui indique au client de renouveler sa requête afin d’utiliser une connexion fraîche.
Ce modèle de programmation (appelé COMET) a été monté en charge et les resultats sont très bons, moins d’une demi seconde de temps de latence sous une charge très importante.
Google utilise cette technique pour le chat intégré à GMail avec apparement un timeout de l’ordre de 30 secondes. Le client léger (appelé GAD) de la plateforme de call center Genesys d’Alcatel Lucent utilise aussi ce mécanisme avec un timeout de l’ordre 10 secondes
Tags: comet | Aucun commentaire »
Publié le 1 février 2008 par Thomas Recloux
Après avoir découvert les continuations de jetty, voici les Advanced IO de Tomcat.
Le modèle de programmation permet aussi de déconnecter les Thread des connexion HTTP, la mise en œuvre me semble un peu plus complexe que pour Jetty mais permet un contrôle plus fin des évènements de la connexion.
Tags: comet, java, tomcat | Un commentaire »
