2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
Dans l'étude précédente, nous avons utilisé JMeter pour effectuer le test d'interface au niveau du protocole pour le système Agileone. Nous savons également que le cœur de la technologie de test de performances consiste à utiliser la technologie multithread pour envoyer des requêtes de protocole afin de compléter la simulation d'un grand nombre d'utilisateurs accédant au système. L'intention de conception originale de JMeter est en fait destinée aux tests de performances. Par exemple, la première étape lorsque nous créons un plan de test consiste à créer un groupe de threads. Cette expérience expliquera comment utiliser JMeter pour effectuer le test de performances de connexion et de publication Phpwind.
But
(1) Maîtriser l'utilisation de la recherche d'association dans JMeter.
(2) Maîtriser la conception et l'utilisation des threads dans JMeter.
(3) Maîtriser l'utilisation des rapports de tests dans JMeter.
processus d'expérimentation
Nous avons créé un total de 100 utilisateurs pour Phpwind de testuser_1 à testuser_100, donc pendant le processus de test de performances, nous devrions implémenter une connexion aléatoire des utilisateurs, afin de mieux simuler des scénarios réels.
(1) Créez un échantillonneur "Requête HTTP", nommez-le "DoLogin" et remplissez les paramètres de requête POST de connexion correspondants.
(2) Créez une « assertion de réponse » et un « affichage de l'arborescence des résultats » pour l'échantillonneur, et il en va de même pour les requêtes ultérieures.
(3) Créez un "pré-processeur" pour l'échantillonneur et implémentez un nombre aléatoire de 1 à 100.
(4) La demande de test finale mise en œuvre est la suivante :
Puisque lors de la publication dans Phpwind, vous devez spécifier un champ "vérifier", dont la valeur est un nombre aléatoire, nous devons utiliser des expressions régulières pour associer la valeur correspondante dans la réponse. Cette partie a été maîtrisée dans le processus d'implémentation des tests d'interface. Ici, nous regardons principalement comment l'implémenter dans JMeter :
(1) Ajoutez un échantillonneur "Requête HTTP" et envoyez une requête GET à "/phpwind/post.php?fid=2" pour obtenir la réponse.
(2) Ajoutez un post-processeur à l'échantillonneur, réglez-le sur "Regular Expression Extractor" et effectuez les réglages suivants :
(3) Une brève explication des champs de saisie ci-dessus :
a) Nom de référence : Le nom du paramètre à référencer dans la prochaine requête. Si vous remplissez verifycode, vous pouvez utiliser ${verifycode} pour le référencer.
b) Expression régulière : Les parenthèses contiennent le contenu à extraire, ce que nous sommes compétents pour appliquer.
c) Modèle : cité avec $-$ Si l'expression régulière que nous définissons trouve plusieurs valeurs, le numéro de séquence indique quelle valeur traiter.
d) Nombres correspondants : 0 représente une valeur aléatoire, 1 représente toutes les valeurs, il suffit généralement de remplir 0.
e) Valeur par défaut : Si le paramètre n'obtient pas de valeur, alors une valeur par défaut est donnée pour qu'il l'obtienne.
(1) Définissez un paramètre utilisateur pour l'échantillonneur et utilisez l'assistant de fonction pour générer un nombre aléatoire pour le titre et le contenu du message.
(2) Utilisez le code de vérification obtenu à l'étape précédente comme valeur du champ de vérification dans le corps de la requête POST.
(3) La demande de test finale générée est la suivante :
Par défaut, JMeter, comme le test d'interface, se charge uniquement du téléchargement de la page actuellement demandée et ne téléchargera pas d'autres ressources supplémentaires de la page. Ce n'est évidemment pas cohérent avec la situation réelle. Nous devons donc télécharger toutes les ressources de la page. Dans l'onglet "Avancé" de l'échantillonneur HTTP, cochez "Obtenir toutes les ressources incluses à partir des fichiers HTML".
Pour cette exécution, nous suivons toujours la même conception de scénario que le script Java précédent : 50 utilisateurs, 5 utilisateurs simultanés toutes les 10 secondes et chaque utilisateur s'exécute 100 fois. Les paramètres spécifiques sont les suivants :
Définir le paramètre « Période de montée en puissance (en secondes) » dans les paramètres ci-dessus sur 100 secondes signifie ajouter un thread toutes les deux secondes. Bien que la fréquence ne puisse pas être définie arbitrairement comme un thread personnalisé, un tel paramètre est cohérent toutes les 10 secondes. Il n'y a pas de différence essentielle dans l'effet de 5 utilisateurs simultanés.
En plus de définir le nombre d'exécutions, nous pouvons également définir la durée totale d'exécution du processus de test de performances. Dans la partie inférieure de l'image ci-dessus, cochez « Planificateur » et définissez la durée. Si nous devons courir en continu pendant une heure, il suffit de définir sa valeur sur 3600 secondes.
Le temps de réflexion est un paramètre nécessaire pour simuler des scénarios utilisateur réels. Le composant "timer" fourni par JMeter est utilisé pour simuler le temps de réflexion de l'utilisateur. JMeter est livré avec de nombreux types de minuteries. Nous utilisons le "minuterie aléatoire gaussienne" plus couramment utilisée. Nous pouvons suivre les étapes suivantes pour créer une minuterie dans JMeter. Un échantillonneur définit le temps de réflexion :
(1) Faites un clic droit sur un échantillonneur, par exemple, nous cliquons sur "DoLogin" pour créer un nouveau "minuteur aléatoire gaussien".
(2) Réglez le décalage sur 2 000 millisecondes et le décalage de retard fixe sur 4 000 millisecondes. Sa fonction est de générer un nombre aléatoire compris entre 4 secondes plus ou moins 2 secondes, c'est-à-dire que le temps de pause aléatoire est compris entre 2 secondes et 6 secondes.
En savoir plus sur l'utilisation de la minuterie JMeter
Le concept de point de rendez-vous a été proposé pour la première fois par l'outil de test de performances LoadRunner. Sa fonction est qu'après qu'un groupe de threads a envoyé une requête, tout le monde se rassemble jusqu'à ce que tous les threads soient synchronisés à un moment donné, puis envoie la requête ensemble. Il est utilisé pour simuler des tests de concurrence plus stricts. Bien que l'utilisation de points de rendez-vous ne soit pas cohérente avec les scénarios réels, elle peut exercer une plus grande pression instantanée sur le serveur. Elle est principalement utilisée pour les tests de concurrence du serveur.
Dans JMeter, nous pouvons utiliser le timer "Synchronizing Timer" pour terminer le traitement des points de rendez-vous. Par exemple, la figure suivante nous montre comment implémenter une stratégie de tests simultanés pour l'échantillonneur « DoPost » :
(1) Nombre d'utilisateurs simulés à regrouper par : Cette valeur correspond au nombre de threads au point de rendez-vous, nous la fixons ici à 50, ce qui signifie qu'une collection doit attendre 50 threads avant d'envoyer la requête suivante ensemble. S'il est défini sur 0 ici, cela signifie utiliser l'ensemble de tous les threads définis par le groupe de threads.
(2) Timeout en millisecondes : Réglez ici sur 10000, ce qui signifie que le timeout du point de rendez-vous est de 10 secondes, c'est-à-dire que si tous les threads n'ont pas attendu 10 secondes, ils n'attendront plus. Le thread qui a terminé la collection envoie directement la requête suivante.
En fait, dans le développement de threads natifs de Java, nous pouvons également utiliser les deux méthodes de synchronisation "wait()" et "notifyAll()" pour compléter la simulation du point de rendez-vous.
JMeter possède également de nombreux composants intégrés pour afficher les rapports de test, mais le plus couramment utilisé est le « rapport d'agrégation » créé pour un certain groupe de threads. Par exemple, les résultats du test de performances Phpwind actuel sont présentés ci-dessous :
Nous pouvons voir sur la figure ci-dessus le nombre d'exécutions de chaque échantillonneur, diverses statistiques mathématiques du temps de réponse (moyenne, médiane, valeur 90 %, valeur minimale, valeur maximale), le taux d'erreur de transaction, la bande passante du réseau, le débit, la taille totale de la réponse, le total taille de la demande et autres données. En plus de surveiller les indicateurs de performances côté serveur, ces indicateurs nous suffisent fondamentalement pour analyser les données de base pour un test de performances.
Exercice de réflexion
(1) Soyez familier avec l'utilisation d'autres composants dans JMeter.
(2) Utilisez JMeter pour réaliser le test de performances d'un projet et résoudre les problèmes rencontrés un par un.
(3) Comparez le test de performances dans JMeter avec le test de performances que nous avons développé nous-mêmes en utilisant Java natif pour voir les similitudes et les différences.
Enfin, je voudrais remercier tous ceux qui ont lu attentivement mon article. En regardant l'augmentation du nombre de fans et de l'attention, il y a toujours une certaine courtoisie. Même si ce n'est pas une chose très précieuse, si vous pouvez l'utiliser, vous pouvez le prendre directement !
Nous devons étudier pour trouver un emploi bien rémunéré. Les questions d'entretien suivantes proviennent des derniers documents d'entretien de sociétés Internet de premier plan telles que Alibaba, Tencent, Byte, etc., et certains patrons de Byte ont donné des réponses faisant autorité après avoir terminé cela. Je crois que tout le monde peut trouver un emploi satisfaisant sur la base des informations recueillies lors de l'entretien.
Il se consacre à la recherche technologique depuis plus de 30 ans et maîtrise divers langages tels que java, linux, javascript, php, css, etc. Il a apporté de nombreuses contributions dans le domaine de l'open source. station de documentation pour les développeurs pour partager certains problèmes de développement technologique pour référence future.
