24 février 2010
Nous sommes heureux de vous proposer le nouveau catalogue de formation Xebia Traning :
Xebia Training se positionne logiquement dans la continuité de Xebia, tant sur la qualité de son offre de formation technique que méthodologique (méthodes agiles), en proposant des formations haut de gamme animées uniquement par les référents de leur domaine.
Avec pour principe premier le refus de tout compromis sur la qualité du formateur et du contenu, Xebia Training fait systématiquement intervenir des acteurs de références dans leurs domaines respectifs.
Nos formations, savant équilibre entre théorie et travaux pratiques, sont destinées à un large public soucieux d’acquérir les meilleures pratiques de notre industrie.
27 janvier 2010
Le premier XKE dans nos nouveaux locaux a donné lieu à de bien curieuses scènes : des bisounours ont hué des poubelles sous le regard moqueur de pokemons ! Et, non, les cartons de déménagement ne nous sont pas tombés sur la tête. Ce n’était là que quelques uns des noms choisis par des équipes de 3 à 4 consultants, qui se sont mesurés dans un concours de tuning de performance, sur une application Java EE standard, buggée (volontairement, pour une fois) par les maîtres de cérémonie, Guillaume Bodet et Cyrille Le Clerc. Tous les participants se sont vus remettre une VM, contenant un Tomcat, une application (PetClinic de Spring, revue et « corrigée ») et des scripts de performance JMeter. Le code source n’a, dans un premier temps, pas été fourni.
Pour tous, un seul but : faire diminuer les temps de réponses de l’application.
Les règles étaient les suivantes :
- Un bug n’est considéré comme trouvé que lorsqu’il a été identifié, qu’un correctif a été proposé et que la preuve est faite que ce correctif permet d’améliorer significativement les temps de réponse.
- Il existe trois niveaux de difficulté, allant du bug évident à l’anomalie la plus fourbe.
- Le choix des outils est libre.
A vos marques… Prêts ? Débuggez !
Lire la suite de cet article »
27 novembre 2009
A Devoxx, deux sessions étaient dédiées au thème du tuning de performance en Java : Performance for the performance-shy par Holly Cummins et The not so dark art of performance tunning par Kirk Pepperdine et Dan Hardiker. Nous nous attardons ici sur cette dernière.
Kirk Pepperdine (photo ci-contre) est Java Champion et possède une expertise reconnue dans le domaine des performances des applications Java. On se souvient également de sa présentation en avril 2008 au ParisJUG où il avait fournit un aperçu des problématiques liées à ce sujet.
Dan Hardiker est pour sa part le fondateur d’une entreprise spécialisée dans l’hosting de solutions basées sur Confluence.
La session qu’ils ont tous deux présentée à Devoxx ne se voulait pas exhaustive sur le sujet de la performance, bien trop vaste et complexe pour être traité en une heure, mais cherchait surtout à mettre en avant des principes et des attitudes à adopter.
Lire la suite de cet article »
6 novembre 2009
Xebia organise une formation d’optimisation des performances d’applications Java/J2EE avec Kirk Pepperdine, une première en France, entre le 18 et 21 janvier 2010.
Pour ceux qui ne le connaissent pas, Kirk Pepperdine dispose de plus de 15 ans d’expérience dans les technologies orientées objets et l’optimisation de la performance. Figure emblématique du monde Java et élu « Champion JAVA » en 2005, Kirk est reconnu comme le référent de l’optimisation de performance Java. Il est le DSI de Kodewerk Ltd et le principal contributeur de javaperformancetuning.com.
Cette formation approfondie de 4 jours permettra aux stagiaires d’obtenir les compétences nécessaires pour optimiser la performance de leurs applications Java/J2EE. Vous aborderez pendant cette formation tous les aspects de la performance :
- L’outillage nécessaire.
- Les méthodologies à appliquer.
- Les concepts d’architecture sous jacents à la performance.
- Les meilleures pratiques.
- Le benchmarking.
- La gestion de mémoire.
Si cette formation vous intéresse, n’hésitez pas à contacter Roderic Pratt au 06.09.69.05.49.
14 octobre 2009
Oracle Coherence est une solution de Data Grid. Elle permet de constituer des grilles de données à l’aide de 4 types de caches:
- Cache distribué: l’ensemble des données est réparti sur les différents nœuds qui composent le cluster Coherence. Afin de garantir une bonne tolérance aux pannes, les données peuvent être sauvegardées sur un ou plusieurs nœuds du cluster. Cette typologie est extrêmement extensible : il suffit d’ajouter des nouveaux nœuds pour augmenter la capacité globale du cache.
- Cache répliqué: l’ensemble des données est répliqué sur l’ensemble des nœuds du cluster. La modification d’une entrée sera propagée à l’ensemble des nœuds. Cette typologie permet d’offrir un accès très rapide en lecture car un seul nœud est sollicité dans l’opération. La contre-partie est que les opérations d’écriture sont lentes et que la taille du cache est indépendante du nombre de nœuds qui composent le cluster.
- Cache local: les données sont conservées exclusivement sur la JVM.
- Near Cache: il permet d’offrir le meilleur des caches de type ‘Répliqué’ (Performance) et de type ‘Distribué’ (Extensibilité) en fournissant un accès rapide aux données accédées le plus fréquemment et le plus récemment. Il est composé de 2 parties:
- le ‘front-cache’ pour les accès locaux, de petite taille, typiquement un cache Local (Local Cache),
- le ‘back-cache’ un cache de plus grande envergure, typiquement un cache distribué (Distributed Cache), qui contient l’ensemble des données avec leurs éventuelles sauvegardes.
Le point fort d’Oracle Coherence est de proposer la même API quelque soit le type de cache. Il est donc possible, par simple configuration, de modifier le type de cache et de l’adapter en fonction des besoins ou de l’environnement: cache local en « Développement », cache distribué en « Intégration », « Near » cache en « Production ».
Lire la suite de cet article »
26 août 2009
Il n’y a rien de plus simple qu’un framework de cache … enfin il paraît. La majorité d’entre eux fonctionne sur un même principe élémentaire, celui que vous décideriez probablement d’adopter si l’on vous demandait d’en développer un : une bonne vieille HashMap ! Logique puisqu’il ne s’agit finalement que d’organiser manuellement un index d’objets vous permettant d’accéder le plus rapidement possible à vos données plutôt que d’aller les piocher dans des sources de données plus gourmandes. Et pourtant, leur utilisation est soumise à un certain nombre de cas d’utilisations offrant de belles occasions de se planter en beauté ! Cet article décrit quelques-uns de ces problèmes, plus précisément les problèmes liés au cache L2 hibernate et caches distribués.
Lire la suite de cet article »
2 juillet 2008
Symptômes
Lors d’un test de performance sur une application J2EE, je note que celle-ci a des soucis de montée en charge. Généralement une ou deux thread dumps peuvent mettre en évidence les points de contentions. Dans mon cas, rien de probant. Je repense alors à l’article publié sur notre blog Chroniques de la performance : À propos de contentions…. Je récupère les sources de l’agent et l’installe sur le serveur d’application, Weblogic 8.1 – JVM 1.4.2. Lancement du tir….
Lire la suite de cet article »
29 novembre 2007
J’ai été, il y a peu, confronté à un problème de performances que l’on peut qualifier d’intéressant – dans la bouche d’un expert technique, ce mot a généralement tendance à provoquer une bouffée de panique chez les plus chevronnés des managers.
Je vous explique.
Le programme consiste à appliquer massivement un traitement identique à un volume important de données – bref, c’est un batch. Objectif opérationnel : assurer la capacité du système à traiter 50000 dossiers par heure.
L’architecture d’exécution de ce batch est relativement classique : un contrôleur est chargé d’obtenir auprès d’un service métier une liste de dossiers à traiter, de segmenter cette liste en lots, puis de soumettre les lots à un pool de threads qui vont réaliser les traitements en parallèle – chaque lot est traité dans une transaction distincte. Le traitement unitaire d’un dossier est relativement long, de l’ordre de 2 secondes ; les lots sont donc petits – 4 dossiers – pour limiter la durée des transactions.
Lire la suite de cet article »
4 octobre 2007
Nous vous proposons aujourd’hui la quatrième d’une série de cinq vidéos consacrées aux problèmes de performances des applications java / J2EE.
Nous y déroulons le top 10 des problèmes de performances en environnement java / J2EE en les illustrant par des cas concrets et en proposant pour chacun des mesures permettant de s’en prémunir.
Cette vidéo traite des numéros :
- 04 : Les bibliothèques tierces
- 03 : Mauvais usage de la concurrence
27 septembre 2007
Nous vous proposons aujourd’hui la troisième d’une série de cinq vidéos consacrées aux problèmes de performances des applications java / J2EE.
Nous y déroulerons le top 10 des problèmes de performances en environnement java / J2EE en les illustrant par des cas concrets et en proposant pour chacun des mesures permettant de s’en prémunir.
Cette vidéo traite des numéros :
- 06 : Utilisation impropre des caches
- 05 : Utilisation excessive de la mémoire
