Articles avec le tag ‘tuning java’

Oups j’ai oublié d’activer les logs GC

1 - Introduction

Votre application vient enfin d’être mise en production après la phase de test (fonctionnel, etc.). Les tests ont été concluant, vous êtes donc serein.

Trois jours après, une alerte remonte sur la consommation mémoire élevée. Pour résoudre ce problème, vous faites appel à un spécialiste qui vous demande les logs GC.

Malheureusement ils n’ont pas été activés et il n’est pas possible d’arrêter le serveur pour ajouter les paramètres à la JVM (en particulier pour -XX:+PrintGCDetails) qui nous permettraient d’avoir ces fameux logs.
Lire la suite de cette entrée »

Optimiser une application JEE : mesurer l’impact sur un cas pratique (3ème partie)

3ème partie de notre saga performance.

Lors de notre dernier article, nous avons pu "faire sauter les verrous" en augmentant le pool de threads qui nous limitait le nombre de traitements simultanés dans la montée en charge. Attardons nous maintenant sur la JVM.

Nous n'allons pas perdre de temps dans le fonctionnement d'une JVM plusieurs articles sauront vous le rappeler très simplement comme le chapitre 3 de cet article qui traite de l'overhead, ou bien celui plus spécifique du fonctionnement de la JVM d'IBM J9.

Partant de cela, allons voir un peu comment la notre préfigure ...

Commençons par activer le port JMX sur notre serveur Glassfish pour introspecter avec un outil de monitoring (plusieurs existent comme JConsole inclue dans le J2SE, VisualVM ...).

Lire la suite de cette entrée »

Optimiser une application JEE : mesurer l’impact sur un cas pratique (2ème partie)

2ème volet de notre analyse de performance :

Après avoir revu les niveaux de logs de notre serveur d'application en 1ère partie d'analyse et en avoir mesuré l'impact du correctif sur le temps de réponse, il est maintenant temps de s'approcher de notre objectif initial : rendre stable l'application avec une moyenne de 1000 utilisateurs actifs simultanés.

On va donc augmenter notre charge et passer de 40vu à 300vu :

Reprenons notre scénario JMeter, augmentons le nombre de threads de 40 à 300 avec un ramp-up de 1 utilisateur supplémentaire toutes les 2 secondes (ce qui laisse suffisamment de temps au serveur pour gérer ses nouvelles allocations de Context Http) :

Lire la suite de cette entrée »

Mots-clés
RSS Feed