Conseils d'experts
Pourquoi tester en charge alors que l'on peut réagir rapidement en cas d'incident ?
Lorsqu'un incident de production survient, le temps de réaction est
compté. Ne sous-estimez pas le temps d'identification du problème et
de sa résolution. En effet depuis la généralisation des architectures n-tiers en couches,
la source des problèmes de performance est difficile à identifier sans outil.
Enfin comment savoir si vos correctifs fonctionnent sans outil de test en charge pour
reproduire les conditions du défaut ?
Peut-on tout régler en ajoutant des machines ?
Les problèmes de performance sont majoritairement liés à une mauvaise configuration logicielle,
une mauvaise configuration réseau ou à la conception même de l'application. Dans ces cas, ajouter
des machines ne règle en rien le problème.
Par exemple, si un pool de connexion à la base de données est limité par erreur à une taille maximale
de 10, il ne pourra jamais y avoir plus de 10 personnes accédant simultanément à une page utilisant la
base de données. Ceci quels que soit la puissance et le nombre des machines utilisées.
Par ailleurs, les systèmes d'informations étant de plus en plus répartis et interconnectés, la complexité
technologique démultiplie le nombre de failles de performance potentielles.
Réalité des coûts financiers d'un test
Pour étudier le coût global de réalisation de tests en charge, il faut tenir compte principalement du coût humain.
En effet, nombre d'outils, de part leur conception ancienne ou résolument trop "technicienne",
n'offrent aucune facilité de réalisation des scénarios de test. La charge humaine pour réaliser ces scénarios peut
rapidement devenir très lourde.
De plus, les modes actuels de développement impliquent des changements réguliers de l'application et la
nécessité d'aligner rapidement les tests avec la dernière version. Donc, il faut prendre en compte le
temps initial nécessaire à la réalisation ainsi que celui nécessaire à ces mises à jour souvent nombreuses.
Plus les scénarios sont aisément réalisés, plus la propension à en accroître le nombre augmente.
Cela vous permet de couvrir plus de cas de tests, donc d'améliorer la qualité globale de votre application.
En conclusion, passez votre temps à tester avec NeoLoad pour améliorer la qualité, et non à développer du code
de test dans un outil mal adapté.
La simplicité de création des scénarios avec NeoLoad vous permet de tester plus et plus vite.
Pourquoi choisir un outil supportant plusieurs technologies (AJAX, Flex, Http/s...) ?
La vie d'une application intranet ou internet comprend de nombreuses évolutions fonctionnelles et techniques.
Ainsi, une première version contient souvent des choix technologiques de base et se
verra agrémenter, au fur et à mesure, de nouvelles technologies pour supporter de nouvelles fonctions métiers
(une interface Flex ou Ajax offrant plus d'ergonomie, ou bien le support de SSL pour des parties sécurisées).
Ainsi, ne faites pas le choix d’un outil limité en terme technologique, faites le
choix NeoLoad, capable de suivre votre croissance et les améliorations de votre application.
Pourquoi utiliser plusieurs injecteurs ?
Il est essentiel que vous soyez libre de choisir -sans coûts- le nombre d'injecteurs servant au test. En effet,
en fonction du nombre d'utilisateurs à simuler, il faut utiliser plusieurs machines pour générer la charge.
En général, la pratique recommande une puissance machine et réseau pour l'injection égale à la
puissance testée.
De plus, en fonction de votre configuration, vous avez potentiellement besoin de générer de la charge à
partir d'un sous réseau ou d'un site distant. Vous devez donc pouvoir disposer
d’un injecteur en un point précis et le commander à distance.
Avec NeoLoad, les injecteurs sont gratuits et illimités.
Surveiller les serveurs implique donc d'installer un élément intrusif ?
Non pas avec NeoLoad ! Grâce à la technologie exclusive des modules de monitoring NeoLoad, vous n'avez rien à installer sur les serveurs à surveiller !
En effet nous utilisons un recueil à distance des informations basé sur les standards déjà disponibles sur chaque plateforme. Depuis
des informations systèmes jusqu'aux données fines issues du JMX pour un serveur J2EE par exemple.
Ainsi vous ne perturbez pas votre système de production et l'analyse de vos tests se fait directement dans NeoLoad !
Comment savoir ce qu'il faut surveiller en premier dans mes serveurs ?
Chaque module de monitoring de NeoLoad est livré préconfiguré. En clair les indicateurs importants pour chaque
serveur ou composant de votre infrastructure ont déjà été identifiés par nos consultants et NeoLoad vous les
propose par défaut. Libre à vous ensuite d'en surveiller des plus pointus. Mais nous ne nous arrêtons pas là :
en effet pour chaque paramètre nous vous indiquons aussi les valeurs des seuils limites issues des meilleures
pratiques de l'industrie. Ainsi même sans connaissance système approfondie, vous détectez automatiquement les
comportements atteignant les limites des capacités de votre architecture et ciblez précisément leur origine.
Peut on générer plus de charge avec des utilisateurs virtuels plus rapides ?
Une idée reçue est que l'on peut mesurer la charge du serveur uniquement en requête par seconde. Cela impliquerait que
peu d'utilisateurs rapides consomment autant de ressources serveur que beaucoup d'utilisateurs lents.
Ce n'est pas le cas, chaque session utilisateur ouverte sur le serveur consomme une certaine quantité
de ressources (mémoire, pools de ressource, connexions réseau).
Diminuer artificiellement le nombre d'utilisateurs virtuels par rapport au nombre réel fausse les résultats de test.
Pour aller plus loin
Contactez-nous pour de plus amples informations.
Découvrez nos solutions.
Essayez NeoLoad 30 jours.
