Archive pour la catégorie ‘Performance applicative’
ContiPerf
1. Introduction
Lorsque l’on fait du développement Java, on ne se préoccupe pas toujours des problèmes de performance. Et lorsque la performance est une contrainte, on ne sait pas toujours comment la mesurer et avec quel outil.
Idéalement, cet outil s'intègrerait à notre environnement de développement et se lancerait automatiquement.
En somme, il nous faudrait un framework comme JUnit mais dédié à la performance.
Présentation de l’outil de génération de jeux de données Benerator
Afin qu'une campagne de tirs de charges soit la plus utile possible, il est souvent nécessaire d'avoir un jeu de données conséquent et réaliste. Pour cela plusieurs solutions existent :
- importation des données de la base de données de production ;
- création du jeu de données à l'aide d'outils maison ;
- utilisation d'ETL ;
- utilisation de l’outil de test de charge et/ou de test fonctionnel afin d’exécuter des scripts qui vont remplir la base ;
- utilisation d'outil de création de données.
Nous allons nous focaliser sur la dernière solution avec l'utilisation de l'outil Benerator qui couvre largement ce besoin.
Lire la suite de cette entrée »
Pourquoi il est dangereux d’utiliser System.gc()
En java, la gestion de la mémoire est réalisée par la JVM, en particulier par le Garbage Collector (ramasse miettes). Or, si l'on regarde d'un peu plus près, on remarque que l'on peut appeler le GC par l'instruction System.gc().
On se dit que cela pourrait être utile afin de libérer un maximum de mémoire avant certains traitements. Cette démarche est fortement déconseillé car c'est une "fausse bonne idée" comme nous allons le démontrer par la suite.
Pourquoi faire attention au volume du jeu de données en base
1. La source du problème
Lorsqu'on développe une application, pour gagner du temps on travaille souvent avec des jeux de données réduits.
En dehors de la question de pure "facilité", cela permet également de :
- réduire le temps d’exécution des requêtes SQL ;
- réduire le temps de chargement de la sauvegarde de la base ;
- avoir toute l'application sur son poste de travail ;
Analyse système et réseau : généralités – Part 2
Après avoir vu comment superviser la partie processeur et mémoire, attardons nous maintenant sur les accès disques et les connexions réseaux.
Monitoring Disk and Network
Cette commande fournit des informations à propos de l'ensemble des périphériques d'entrée et sortie : les disques, le ou les terminaux, les autres périphériques séries.
1. La commande Iostat (ou sar -d)
La syntaxe de base est la suivante :
iostat interval count
Pourquoi désactiver les plugins du navigateur Web lors de l’enregistrement d’un scénario ?
Dans la majorité des outils de test de charge (HP LoadRunner, Apache JMeter, Microfocus SilkPerformer...) l'enregistrement des scripts est réalisé à l'aide d'un proxy. Toutes les requêtes qui passent par ce proxy sont enregistrées et l'on peut donc se retrouver avec des requêtes qui n'ont rien à faire dans notre script, en particulier si certains plugins sont installés dans le navigateur Web utilisé pour notre enregistrement.
Ces requêtes inutiles vont faire appel à des environnements externes à celui qu'on teste et vont poser un certain nombre de problèmes comme :
-
avoir des temps de réponse faussés, dû à l'attente d’acquittement des sites externes ;
-
se faire black-lister par l'environnement externe ;
Optimiser Tomcat : les bests practices – Part 2
Après avoir abordé les problématiques liées à la gestion de la Heap et des threads, voici une liste des paramètres principaux restants à aborder. (liste non-exhaustive évidemment !)
Le Tuning HTTP et TCP
Avant de s’attaquer à ces améliorations, il est important de comprendre et d'agir en fonction des connectors utilisés par votre serveur :
Blocking IO Connector
Pourquoi tester les résultats de chaque requête dans un script de test de charge ?
Il peut être tentant dans un script de test de charge de ne pas tester le résultat de chaque requête. Mais en faisant cela, on s'expose à de graves problèmes pouvant fausser les résultats.
Car si le résultat de la requête n'est pas testé, on ne sait pas si elle s'exécute avec succès et donc le résultat final du tir de charge proposera des moyennes de valeurs complètement faussées.
Cela revient à additionner des patates avec des carottes et comme nous l'ont appris nos professeurs, cela n'a aucun sens.
Pourquoi la corrélation des actions/écrans est importante.
Après l'enregistrement JMeter à l'aide d'un proxy de notre script de test, on obtient fréquemment des variables qui sont passés d'un écran à l'autre soit en GET, soit en POST. Ces variables permettent essentiellement de :
-
personnaliser la session utilisateur (identification de session unique, pour chaque création de session utilisateur;
-
passer des valeurs de formulaires ;
Optimiser Tomcat : les bests practices – Part 1
Cet article devrait vous donner un petit coup de pouce sur les principes d'optimisation d'un serveur d'application, ici Tomcat.
Avant d'aborder les quelques points techniques, il est indispensable d'avoir à l'esprit que quel que soit la qualité d'implémentation de votre application, il est indispensable de bien définir les attentes (NFR) de votre infrastructure.
En effet pour optimiser un serveur ou un cluster, il faut avant tout connaitre le type d'utilisation que l'on va attendre de lui. Ainsi la configuration d'un serveur qui va traiter des gros volumes d'entrée avec des traitements simples, ne ressemblera en rien à celle d'un serveur encaissant des gros traitements pour une volumétrie d'utilisation limitée !
Quelques conseils majeurs avant même d'entrer dans le vif du sujet :
