1 mars 2010
Revue de Presse Xebia
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
Agilité
Le coin de la technique
21 septembre 2009
Revue de presse
La revue de presse de l’actualitéava/J2EE hebdomadaire proposépar Xebia.
Actualité éditeurs / SSII
- Google lance son langage pour la JVM
- iBeans : la solution d’intégration pour applications Web de MuleSoft
Agilité
SOA
Le coin de la technique
- OSGi 4.2
- Scala OSGi-fié
- Astuces de performance pour MySQL
- Enquête sur les temps de redémarrage des serveurs JEE
- Premiers pas avec memcached
Evènements de notre communauté en France et à l’étranger
2 janvier 2009
Ce que vous avez peut-être raté au quatrième trimestre 2008
Voici la liste des billets les plus lus sur ce blog en octobre, novembre et décembre :
RIA Contest : Flex / Silverlight / GWT / Echo3 / JavaFX
Après le Xebia Web Framework Contest de l’année dernière, le thème du XKE du mois d’Octobre était un nouveau contest dédié aux RIA.
Le but de cette journée était de développer une application de gestion de playlist de morceaux de musique. En promoteurs des méthodes Agiles, les spécifications furent données sous forme d’un Product Backlog. Trois sprints d’une durée de 90 minutes ont permis à tous de suivre l’évolution des différentes réalisations. Un web service SOAP fournissait les différentes données: Artiste, Album, Titres et Pochettes d’album.
Cinq équipes ont été constituées, cinq frameworks ont donc été choisis :
Au terme de cette journée, chaque équipe a pu exprimer un retour d’expérience significatif.
Diagnostic d’une JVM à distance
Développer une application Java, c’est bien. La rendre performante, c’est mieux.
Cependant, qui dit « performance », dit « mesure ». En effet, il est nécessaire de pouvoir :
- connaître les paramètres de lancement de la JVM,
- mesurer l’empreinte mémoire et le comportement du Garbage Collector,
Cet article va décrire dans une première partie les différents outils permettant de collecter ces informations en local. La seconde partie se concentre sur les moyens pour obtenir ces mêmes informations à distance.
Analyse mémoire d’une JVM
Mardi, 10 heures
- La production « Allo, le projet, depuis 10 minutes on voit passer des messages ‘OutOfMemoryError’. Que fait-on ? «
- Le projet « Augmentez la mémoire de la JVM, doublez-la valeur de l’option -Xmx «
Mardi, 13 heures
- La production « Allo, le projet, depuis 5 minutes on voit encore passer des messages ‘OutOfMemoryError’. Que fait-on ? «
- Le projet « Augmentez la mémoire de la JVM, doublez encore la valeur de l’option -Xmx «
Mardi 18 heures
- La production « Allo, le projet, depuis 2 minutes on voit passer encore des messages ‘OutOfMemoryError’. Que fait-on ? «
- Le projet « Tut, tut, tut,….. »
- La production « Plus d’équipe projet, la nuit va être longue… »
Cette petite scène est un classique, un air de déjà-vu mais que faire ? Si votre application a déjà subi une batterie de tests techniques, augmenter la mémoire est rarement la bonne solution. La scène décrite ci-dessus laisse penser à ce que l’on appelle classiquement une Fuite Mémoire (Memory Leak). En réalité, avec les JVM récentes, la fuite mémoire n’existe pas, je préfère parler d’accumulation d’objets non désirés. Cet article va vous montrer comment débusquer cette accumulation avec les outils jmap, jhat et Eclipse Memory Analyser.
27 novembre 2008
Analyse mémoire d’une JVM
Mardi, 10 heures
- La production « Allo, le projet, depuis 10 minutes on voit passer des messages ‘OutOfMemoryError’. Que fait-on ? «
- Le projet « Augmentez la mémoire de la JVM, doublez-la valeur de l’option -Xmx «
Mardi, 13 heures
- La production « Allo, le projet, depuis 5 minutes on voit encore passer des messages ‘OutOfMemoryError’. Que fait-on ? «
- Le projet « Augmentez la mémoire de la JVM, doublez encore la valeur de l’option -Xmx «
Mardi 18 heures
- La production « Allo, le projet, depuis 2 minutes on voit passer encore des messages ‘OutOfMemoryError’. Que fait-on ? «
- Le projet « Tut, tut, tut,….. »
- La production « Plus d’équipe projet, la nuit va être longue… »
Cette petite scène est un classique, un air de déjà-vu mais que faire ? Si votre application a déjà subi une batterie de tests techniques, augmenter la mémoire est rarement la bonne solution. La scène décrite ci-dessus laisse penser à ce que l’on appelle classiquement une Fuite Mémoire (Memory Leak). En réalité, avec les JVM récentes, la fuite mémoire n’existe pas, je préfère parler d’accumulation d’objets non désirés. Cet article va vous montrer comment débusquer cette accumulation avec les outils jmap, jhat et Eclipse Memory Analyser
jmap
jmap est l’outil qui permet d’effectuer des photographies de la mémoire d’une JVM. Deux options sont particulièrement intéressantes : l’histogramme et le dump.
27 octobre 2008
Revue de Presse Xebia
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
Le coin de la technique
22 octobre 2008
Diagnostic d’une JVM à distance
Développer une application Java, c’est bien. La rendre performante, c’est mieux.
Cependant, qui dit « performance », dit « mesure ». En effet, il est nécessaire de pouvoir :
- connaître les paramètres de lancement de la JVM,
- mesurer l’empreinte mémoire et le comportement du Garbage Collector,
Cet article va décrire dans une première partie les différents outils permettant de collecter ces informations en local. La seconde partie se concentre sur les moyens pour obtenir ces mêmes informations à distance.
22 septembre 2008
Revue de Presse Xebia
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Agilité
Le coin de la technique
15 septembre 2008
Revue de Presse Xebia
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Le coin de la technique
invokedynamicvu de l’intérieur- Concurrency : past and present
- Tuning des JVM Websphere 6.1
- Performance d’affichage d’une page Web
Evènements de notre communauté en France et à l’étranger
21 juillet 2008
Revue de Presse Xebia
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
RIA
Le coin de la technique
12 mars 2008
GC générationnels traditionnels (jdk6) VS GC Garbage First (jdk7)
L’analyse empirique montre que dans une application la très grande majorité des objets créés sont détruits presque immédiatement. C’est d’autant plus vrai pour les applications web et/ou stateless où la plupart des objets sont créés pour traiter une requête et peuvent être donc détruits juste après ce traitement. De ce constat résulte l’idée de ne pas traiter de la même façon les objets fraîchement créés et ceux qui existent depuis plus longtemps. Les Garbage Collector qui utilisent des implémentations basées sur ce principe sont appelés GC générationnels. On peut fixer deux catégories d’objectifs lorsque l’on optimise le GC : réduire les pauses ou augmenter le débit. Ces objectifs sont en général orthogonaux (la réduction de la durée des pauses se fait au détriment du débit, et vice-versa), ils dépendent souvent du type d’applications : dans une application interactive, nous privilégierons les pauses, et au contraire, dans un batch, seul le débit compte.
La suite du billet est décomposée en deux parties :
- La première décrit le fonctionnement des algorithmes générationnels traditionnels (Implémentation actuelle des JVM Sun)
- La seconde détaille le nouvel algorithme que Sun essaye de pousser pour sa future JVM