La réalisation de tests de charge sur des protocoles basés sur des sockets nécessite une configuration précise dans Apache JMeter. Cet article détaille la mise en œuvre de tests de performance pour des flux de données binaires via le protocole TCP.
Sélection de l'implémentation du client TCP
JMeter propose trois classes principales pour gérer les échanges de données via TCP. Le choix dépend de la structure de vos paquets de données :
- TCPClientImpl : Utilisé pour les échanges de texte simple. Il traite les données comme des chaînes de caractères selon un encodage défini.
- BinaryTCPClientImpl : Conçu pour les données binaires représentées sous forme de chaînes hexadécimales. C'est l'option privilégiée pour les protocoles propriétaires complexes.
- LengthPrefixedBinaryTCPClientImpl : Similaire à la version binaire, mais ajoute automatiquement un préfixe indiquant la longueur des données avant l'envoi.
Pour un contrôle granulaire des trames, nous utiliserons BinaryTCPClientImpl. La première étape consiste à configurer JMeter pour utiliser cette classe par défaut dans le fichier jmeter.properties :
# Définition de l'implémentation par défaut dans bin/jmeter.properties
tcp.handler=BinaryTCPClientImpl
Résolution des problèmes de blocage de connexion
Un problème fréquent lors des tests TCP est le blocage du thread JMeter. Cela se produit lorsque le client attend indéfiniment une réponse sans détecter la fin du flux. JMeter doit savoir quand arrêter la lecture du socket via un caractère de fin de message (EOL - End of Line ou EOM - End of Message).
Contrairement aux paramètres standards, l'implémentation binaire nécessite une propriété spécifique. Il faut convertir l'octet de fin de votre message (en base 10) et l'injecter dans la configuration. La valeur doit être comprise entre -128 et 127.
# Configuration du délimiteur de fin pour le client binaire
# Exemple : si votre message se termine par 0x80, la valeur décimale est -128
tcp.BinaryTCPClient.eomByte=-128
Si votre protocole ne possède pas de délimiteur naturel, il est souvent nécessaire d'ajouter un octet de contrôle à la fin de la trame côté serveur ou d'ajuster le comportement du simulateur pour clore le flux proprement.
Gestion des séquences métier complexes (Multi-échanges)
Certains scénarios nécessitent plusieurs échanges de données (handshake, authentification, puis données) sur une seule et même connexion socket avant de fermer la session.
Pour orchestrer cela, on utilise la combinaison des options Re-use connection (Réutiliser la connexion) et Close connection (Fermer la connexion) sur les échantillonneurs TCP :
- Échantillonneurs intermédiaires : Cochez l'option Re-use connection et laissez Close connection décochée. Cela permet de maintenir le tunnel ouvert pour les requêtes suivantes.
- Dernier échantillonneur de la séquence : Gardez Re-use connection actif mais cochez Close connection. Le socket sera libéré après la réception de la dernière réponse, permettant au thread de démarrer une nouvelle itération proprement.
Regroupement et analyse des résultats
Pour obtenir des métriques représentatives d'une transaction complète plutôt que de chaque paquet individuel, il est recommandé d'encapsuler vos échantillonneurs TCP dans un Contrôleur de Transaction (Transaction Controller).
En activant l'option "Generate parent sample", JMeter agrégera le temps de réponse total de la séquence, incluant les temps de latence de chaque étape, offrant ainsi une vision précise de la performance du processus métier global.
Structure du Plan de Test :
└── Groupe d'unités (Thread Group)
└── Contrôleur de Transaction
├── Requête TCP 1 (Handshake) - Re-use: ON, Close: OFF
├── Requête TCP 2 (Data Exchange) - Re-use: ON, Close: OFF
└── Requête TCP 3 (Finalize) - Re-use: ON, Close: ON