JMeter WebSocket

Que sont les Websockets ? #

WebSocket sont un protocole de communication bidirectionnelle et persistent entre le client et la serveur, bien que basé sur le protocol TCP, l’échange d’informations est effectué asynchronement, ce qui ressemble plus à une modélisation non orientée comme UDP. WebSocket ont été introduits avec les mises à jour HTML 5 et peuvent utiliser les ports 80 et 443 pour des communications sécurisées ou non sécurisées :

1. port 80 pour ws://
2. port 443 pour wss://

Communication commence par une négociation et une échange d’informations qui peuvent prendre la forme de HTTP ou HTTPS vers WS ou WSS, la principale différence entre HTTP et WS est que après le transfert d’informations entre le client et serveur, HTTP ferme la connexion tandis que WS maintient-la ouverte pour les envois de mises à jour.

Voici un exemple d’une demande de client et de réponse du serveur : #

GET /chat HTTP/1.1
Host: chatserver.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: c2FtcGxlZGF0YQ==
Sec-WebSocket-Origin: http://chatserver.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

Exemple du réponse HTTP de la serveur pour changer le protocole en WS #

HTTP/1.1 101 Switching Protocols
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Accept: ek8sYU8WRgY4WUU=
Sec-WebSocket-Protocol: chat

Qu’est-ce que les WebSocket sont pour? #

Les WebSocket sont principalement utilisés pour la messagerie asynchrone et il n’y a pas de meilleur exemple de cela que les applications chat, bien qu’ils aient d’autres usages dans les SPA (applications à une page unique). La communication via chat est asynchrone car nous ne savons pas quand le client ou le serveur répondra à notre message. Cela s’applique également aux chatbots, surtout si votre intention est de réaliser des tests jusqu’au bout. Tels types de tests n’ont rien à voir avec les tests ML (Machine Learning) qui sont effectués en utilisant des modèles de chatbots. Les WebSocket établissent une seule canal ou port pour transmettre les messages ou les mises à jour, ce qui peut être envoyées indéfiniment entre les deux acteurs à tout moment dans le temps, créant ainsi un sentiment de communication en temps réel. La communication n’est pas illimitée; il y a une durée maximale d’attente après laquelle si aucune mise à jour ne sont disponibles, la connexion est terminée.

Comment tester les WebSocket ? #

Les WebSocket peuvent être testés avec JMeter en utilisant des extensions, et nous avons deux options :

• WebSocket Sampler by Maciej Zaleski

  

• WebSocket Samplers by Peter Doornbosch

  

Commencez par l’ajout de Maciej, qui je crois est une excellente addition pour les tests de charge et de stress. Bien que cela puisse être un peu oxydaté, il y a des choses qu’il faudrait considérer avant de commencer le test. Lorsque vous envoyez des messages par le biais du moyen, la réponse arrive très probablement presque instantanément ou légèrement tardivement, même recevant deux réponses dans une courte période de temps. Cela est dû à la façon dont JMeter et son moteur sont conçus en mode synchronisé, ce qui rend difficile l’évaluation des temps de réponse précis. Cependant, il existe d’autres outils qui peuvent accomplir cette tâche mieux, qui nous seront présentés dans les conclusions.

Websockets - Terminologie #

Nom du serveur ou adresse IP: Le nom du serveur ou l’adresse IP du serveur.
Port Numéro: Le numéro de port utilisé, peut être 80 ou 443 selon qu’il est sécurisé ou non.
Temps d’attente pour la connexion: Valeur maximale en millisecondes pour la création d’une connexion.
Temps d’attente pour le lecteur/la réception de réponse: Valeur maximale en millisecondes pour lire ou recevoir une réponse.
Protocole: Le protocole de communication, peut être WS ou WSS.

WebSocket de Maciej’s #

Implémentation: Seul disponible dans RFC6455 (v13) comme la dernière standard pour le protocole.
Connexion en streaming: Indique si la connexion est réutilisée ou terminée après avoir utilisé le canal.
Données de requête: Les messages textuels ou binaires qui seront envoyés au serveur.
Pattern de réponse: Le modèle avec lequel nous pouvons conclure le message.
Pattern de fermeture de connexion: Le modèle avec lequel nous pouvons conclure la connexion.
Stockage des messages: Définit le nombre maximum de messages que l’on peut stocker avant de fermer le lecteur.

1.- Installez l’add-on et relancez #

Premièrement, nous devons installer le add-on de Maciej Zaleski développé par lui-même depuis la gestion des extensions JMeter. Bien que ce soit également disponible sur son site Github en tant qu’extension JAR, il est préférable d’utiliser le manager pour installer les dépendances appropriées. Une fois l’add-on installé, nous relancerons JMeter et validerons que l’add-on WebSocket sampler est disponible dans la zone des Samplers.

2.- Configurez le lecteur. #

Une fois que le lecteur est ajouté, nous procédons à la configuration des informations nécessaires pour établir la communication. Pour ce faire, nous utiliserons le site de test websocket.org, qui doit contenir les informations suivantes :

Nom du serveur ou IP: echo.websocket.org
Port: 80
Timeout de connexion: 500 ms
Timeout de réponse: 2000 ms
Protocole: ws
Paramètres: encoding=text
Données de requête Hello

3.- Vérifiez la Réponse #

Après avoir configuré le WebSocket Mule, nous devons tester que cela fonctionne. Nous devons ajouter un écouteur de tâche résultat pour voir la réponse du serveur, qui est une simple echo locale qui répondra avec ce que vous lui envoyez. Si votre script n’a pas fonctionné comme prévu, voici un lien vers un exemple.

WebSocket de Peter #

Connexion WebSocket ouverte : Établir une connexion en utilisant les protocoles WS ou WSS.
Messages Ping/Pong : Envoyer des messages pour maintenir la communication active.
Sampler Request-Response : Envoyer ou recevoir du texte ou du format binaire de données.
Sampler Single Write : Envoyer ou recevoir des informations en textes ou formats binaires.
Sampler Single Read : Recevoir des informations en textes ou formats binaires.
Fermer la connexion : Fermer le canal de communication.

1.- Install the add-on and restart #

Install the WebSocket add-on developed by Peter Doornbosch from JMeter’s Add-ons manager, although it is also available as a JAR in its Bitbucket site. It is preferable to use the Add-ons manager for installing the required dependencies. Once the add-on is installed, restart JMeter and validate that the WebSocket mappers are available within the Mappers area.

2.- Configurer #

Cette addition diffère de la précédente car elle nécessite une série de mousquetaires pour établir la communication, maintenir-la, envoyer des informations et finalement fermer le canal. Pour commencer, nous devons placer un “Connexion WebSocket Ouverte” afin d’initier la communication avec les informations suivantes :

Nom du serveur ou adresse IP: echo.websocket.org
Numéro de port: 80
Durée d’attente de connexion: 500 ms
Durée d’attente de lecture: 2000 ms
Protocole: ws

Après la configuration de la module de connexion, nous devons utiliser le “Sampler WebSocket Unic” pour envoyer des informations au canal. Nous devons toujours activer l’ancienne connexion que c’est le premier bouton radio.

Bonjour

Le texte suivant doit être ajouté : “Sampler WebSocket Un seul lecture” pour lire les informations du canal. De même, nous devons sélectionner l’option d’utiliser une connexion existante.

Nous devons également ajouter la “Ping/Pong WebSocket” pour maintenir l’ouverture de la chaîne de communication, ainsi que sélectionner l’option d’utiliser une connexion existante.

Pour terminer cela, nous devons ajouter la “Fermeture WebSocket” pour fermer le canal et mettre fin à la communication.

3.- Essayer-le #

Après avoir configuré le lecteur WebSocket, nous devons tester que cela fonctionne. Nous devons ajouter un Listeneur de Résultat pour voir la réponse du serveur, qui est une simple répétition locale qui répondra avec ce que vous envoyez. Si votre Script n’a pas fonctionné comme prévu, voici un lien vers un exemple.

Est JMeter une bonne option pour tester les WebSocket? #

La réponse n’est pas simple, mais je crois qu’elle peut faire la job assez bien si votre objectif est simplement de tester le système et d’évaluer la performance. Si vous avez besoin de timing précis des temps de réponse, elle pourrait fonctionner correctement avec des patterns pour les réponses ou la fermeture du connexion, qui est également importante lorsqu’on optimise les ressources. Généralement, JMeter est une bonne option, mais dépend fortement sur le cadre de l’examen. Il n’est pas la force forte de JMeter en testant les WebSocket, car il est un outil synchronique qui limite sa perspective quelque peu.

Conclusion #

JMeter est une option valide pour ce travail aussi. La répétition et l’authenticité des tokens peuvent être envoyés par le biais de la canalisation. En somme, pratiquement tout fichier ou données peut être transmis car il supporte également un transfert binaire. Cependant, dans la même manière que j’ai essayé d’y transmettre dans mes publications précédentes, JMeter n’est pas l’option la plus appropriée pour ces types de tests ; il y a d’autres outils comme Gatling, Artillery ou K6 qui ont été conçus avec des moteurs asynchrônes qui sont mieux adaptés à tels types de tests. De plus, pour la scaling, car il est asynchrone le transfert de requêtes, beaucoup peuvent être envoyées sans que les threads ne restent en attente du répondant, mais cela implique également d’observer attentivement les ressources comme la réseaux ou l’espace mémoire, car facilement surcharger les générateurs de charge et ce bénéfice pourrait devenir une catastrophe.