Dans ce premier billet, je vous présentais la solution de test de charge dans les nuages BlazeMeter, basée sur l’outil Apache JMeter, illustré par un petit test. Dans ce nouveau billet, on passe aux choses sérieuses : le (très) gros test de charge.
Mon objectif était le suivant : faire un tir de charge avec 100 000 utilisateurs virtuels actifs.
Pour faire ce type de gros test, depuis les nuages, il faut un serveur cible (ou une solution cible). Pour ma part, j’ai eu la possibilité d’avoir un prêt d’un très gros serveur situé dans un centre de données à Poitiers/France connecté directement sur une importante dorsale Internet via une liaison à 100 MBits/s. Autrement dit le serveur était bien placé sur Internet pour être attaqué par la solution BlazeMeter.
Le serveur en question est un Dell R815, ayant 4 CPU de 12 cœurs chacun (AMD Opteron 6176), soit 48 coeurs, accompagné de 256 Go de mémoire RAM, connecté à 1 Gbits/s (en ip bonding) sur un commutateur en liaison avec un pare-feu BSD (en mode NAT). Le système d’exploitation dudit serveur est GNU/Linux Debian 6.0.5 en 64 bits.
Le serveur était totalement disponible pour ce test (pas d’autres services tournant dessus).
L’idée étant de faire un test de charge pour « tester » la solution BlazeMeter, et non pas de tester la performance du serveur cible, j’ai choisi de ne mettre qu’un serveur Web Apache avec 3 pages HTML statiques. Le serveur Apache est configuré avec mod_deflate et mod_cache.
Le scénario de test sera le suivant :
- page d’accueil (+assertion réponse)
- page A (+assertion réponse)
- page B (+assertion réponse)
- pas de ressources statiques (pour préserver la bande passante)
- 5 secondes de pause entre chaque page
- 1 itération par minute pour chaque utilisateur virtuel
- les requêtes HTTP utilisent l’implémentation HttpClient 4 Continuer la lecture de Rapport de (très) gros test de charge avec la solution BlazeMeter
