17. Au secours ! Mon patron veut que je teste en charge notre application ! ¶

C'est une proposition assez ouverte. Il y a un certain nombre de questions à poser en premier, et en plus un certain nombre de ressources qui seront nécessaires. Vous aurez besoin de matériel pour exécuter les benchmarks/tests de charge à partir de. Un certain nombre d'outils s'avéreront utiles. Il existe un certain nombre de produits à considérer. Et enfin, pourquoi Java est-il un bon choix pour implémenter un produit de test de charge/benchmarking.

17.1 Questions à poser ¶

Quel est le nombre moyen d'utilisateurs prévu (charge normale) ?

Quel est notre nombre maximal d'utilisateurs prévu ?

Quel est le bon moment pour tester en charge notre application (c'est-à-dire en dehors des heures de travail ou les week-ends), en gardant à l'esprit que cela peut très bien faire planter un ou plusieurs de nos serveurs ?

Notre application a-t-elle un état ? Si oui, comment notre application le gère-t-elle (cookies, réécriture de session ou autre méthode) ?

Quel est l'objectif du test ?

17.2 Ressources ¶

Les ressources suivantes s'avéreront très utiles. Gardez à l'esprit que si vous ne pouvez pas localiser ces ressources, vous deviendrez ces ressources. Comme vous avez déjà du pain sur la planche, il est utile de savoir qui sont les personnes suivantes, afin de pouvoir leur demander de l'aide si vous en avez besoin.

17.2.1 Réseau ¶

Qui connaît la topologie de notre réseau ? Si vous rencontrez des problèmes de pare-feu ou de proxy, cela deviendra très important. De plus, un réseau de test privé (qui aura donc une très faible latence réseau) serait une très bonne chose. Savoir qui peut vous en créer un (si vous le jugez nécessaire) vous sera très utile. Si l'application ne s'adapte pas comme prévu, qui peut ajouter du matériel supplémentaire ?

17.2.2 Application ¶

Qui sait comment fonctionne notre application ? La séquence normale est

test (faible volume - pouvons-nous comparer notre application ?)
référence (le nombre moyen d'utilisateurs)
load-test (le nombre maximum d'utilisateurs)
tester de manière destructive (quelle est notre limite stricte ?)

Le processus de test peut évoluer du test de la boîte noire au test de la boîte blanche (la différence est que le premier ne nécessite aucune connaissance de l'application [il est traité comme une "boîte noire"] tandis que le second nécessite une certaine connaissance de l'application). Il n'est pas rare de découvrir des problèmes avec l'application au cours de ce processus, alors soyez prêt à défendre votre travail.

17.3 Quelle plate-forme dois-je utiliser pour exécuter les benchmarks/tests de charge ? ¶

Il doit s'agir d'un matériel largement utilisé, avec une installation logicielle standard (c'est-à-dire vanille). N'oubliez pas que si vous publiez vos résultats, la première chose que vos clients feront est d'embaucher un étudiant diplômé pour les vérifier. Vous pourriez aussi bien rendre les choses aussi faciles que possible pour cette personne.

Pour Windows, Windows XP Professionnel devrait être un minimum (les autres ne multithreadent pas au-delà de 50 à 60 connexions, et vous prévoyez probablement plus d'utilisateurs que cela).

Les bonnes plates-formes gratuites incluent les Linux, les BSD et Solaris Intel. Si vous avez un peu plus d'argent, il existe des Linux commerciaux. Cela peut valoir la peine si vous avez besoin d'aide.

Pour les plates-formes non Windows, étudiez " ulimit -n unlimited " en vue de l'inclure dans les scripts de démarrage de votre compte utilisateur (scripts .bashrc ou .cshrc pour le compte de test).

Notez également que certaines éditions Linux/Unix sont destinées à une utilisation serveur. Ceux-ci ont généralement une prise en charge minimale ou nulle de l'interface graphique. De tels systèmes d'exploitation devraient convenir pour exécuter JMeter en mode CLI, mais le mode GUI de JMeter ne fonctionnera probablement pas à moins que vous n'installiez un environnement GUI minimal.

Au fur et à mesure que vous progresserez vers des benchmarks/tests de charge à plus grande échelle, cette plate-forme deviendra le facteur limitant. Il vaut donc la peine d'utiliser le meilleur matériel et logiciel dont vous disposez. N'oubliez pas d'inclure la configuration matérielle/logicielle dans vos benchmarks publiés.

Lorsque vous avez besoin de beaucoup de machines ou que vous souhaitez tester la latence du réseau, Cloud peut vous aider. JMeter peut facilement être installé sur des instances Cloud car il s'exécute sur presque toutes les architectures disponibles dans le Cloud. JMeter est également pris en charge dans Commercial Cloud PAAS si vous ne souhaitez pas le gérer vous-même.

N'oubliez pas le mode JMeter batch (CLI). Ce mode doit être utilisé lors des tests de charge pour de nombreuses raisons :

Si vous avez un serveur puissant qui prend en charge Java mais qui n'a peut-être pas une implémentation graphique rapide, ou sur lequel vous devez vous connecter à distance.
Le mode batch (CLI) peut réduire le trafic réseau par rapport à l'utilisation d'un affichage à distance ou du mode client-serveur.
Java AWT Thread utilisé pour le mode GUI peut modifier le comportement d'injection en bloquant parfois

Le fichier journal par lots peut ensuite être chargé dans JMeter sur un poste de travail pour analyse, ou vous pouvez utiliser la sortie CSV et importer les données dans une feuille de calcul.

Rappelez-vous que le mode GUI est pour la création et le débogage de scripts, pas pour les tests de charge

17.4 Outils ¶

Les outils suivants vous seront tous utiles. Il vaut vraiment la peine de se familiariser avec eux. Cela devrait inclure les essayer et lire la documentation appropriée (pages de manuel, fichiers d'informations, messages d'application --help et toute documentation fournie).

17.4.1 ping ¶

Cela peut être utilisé pour déterminer si vous pouvez ou non atteindre votre site cible. Des options peuvent être spécifiées pour que ' ping ' fournisse le même type de rapport d'itinéraire que ' traceroute '.

17.4.2 nslookup/dig ¶

Bien que l' utilisateur utilise normalement une adresse Internet lisible par l'homme, vous souhaiterez peut-être éviter la surcharge des recherches DNS lors de l'analyse comparative/des tests de charge. Ceux-ci peuvent être utilisés pour déterminer l'adresse unique (quad pointillé) de votre site cible.

17.4.3 traceroute ¶

Si vous ne pouvez pas « pinger » votre site cible, cela peut être utilisé pour déterminer le problème (éventuellement un pare-feu ou un proxy). Il peut également être utilisé pour estimer la latence globale du réseau (l'exécution locale devrait donner la latence réseau la plus faible possible - rappelez-vous que vos utilisateurs fonctionneront sur un Internet éventuellement occupé). Généralement, moins il y a de sauts, mieux c'est.

17.5 Comment puis-je améliorer JMeter ? ¶

Il existe de nombreux fournisseurs open source et commerciaux qui fournissent des plug-ins JMeter ou d'autres ressources à utiliser avec JMeter. Certains d'entre eux sont répertoriés sur le Wiki JMeter. Ils sont classés en plusieurs catégories :

JMeterPlugins - plugins pour étendre JMeter
JMeterAddons - addons à utiliser avec JMeter, par exemple des plugins pour les navigateurs, Maven et Jenkins.
JMeterServices - ^Services tiers, par exemple JMeter basé sur le cloud

Notez que leur apparition sur le Wiki n'implique aucune approbation par le projet Apache JMeter. Toute demande d'assistance doit être adressée au fournisseur concerné.

17.6 Pourquoi Java ? ¶

Pourquoi pas Perl ou C ?

Eh bien, Perl pourrait être un très bon choix sauf que le package Benchmark semble donner des résultats assez flous. De plus, simuler plusieurs utilisateurs avec Perl est une proposition délicate (plusieurs connexions peuvent être simulées en bifurquant de nombreux processus à partir d'un script shell, mais ce ne seront pas des threads, ce seront des processus). Cependant, la communauté Perl est très grande. Si vous trouvez que quelqu'un a déjà écrit quelque chose qui semble utile, cela pourrait être une très bonne solution.

C, bien sûr, est un très bon choix (consultez l' outil Apache ab ). Mais soyez prêt à écrire tout le code de gestion de réseau, de threading et d'état personnalisé dont vous aurez besoin pour évaluer votre application.

Java vous offre (gratuitement) le code personnalisé de gestion de réseau, de threading et d'état dont vous aurez besoin pour évaluer votre application. Java est conscient de HTTP, FTP et HTTPS - ainsi que de RMI, IIOP et JDBC (sans parler des cookies, de l'encodage d'URL et de la réécriture d'URL). De plus, Java vous offre une récupération automatique des déchets et une sécurité au niveau du code octet.

Go to top