Ce scénario est-il un test de résistance valide?

Question

J'ai une application serveur qui traite les demandes des clients de différentes manières.

Je veux savoir combien d'utilisateurs peuvent être servis avec un temps de latence minimal. J'ai donc réalisé une petite application de test de contrainte qui simule les demandes des utilisateurs. Simultanément, une autre application surveille l'utilisation de la mémoire / du processeur.

L'outil de test de contrainte crée un fil toutes les secondes où chaque fil représente un utilisateur. Si le test de stress ne peut pas créer de nouveau thread en raison du manque de ressources, il démarre une nouvelle instance de l'outil de test de stress.

Le problème est que chaque thread écrit dans le fichier la latence de chaque requête et le nombre actuel de threads en cours d'exécution, ce qui pose un problème d'E / S car après quelques minutes, vous avez beaucoup de threads devant écrire sur le disque. ce comportement n'existera pas dans le scénario réel car le client demande uniquement les données.

Comment résoudre ce problème car je souhaite mesurer la latence maximale par utilisateur?

PS:

Certaines réponses indiquent qu’il faut exécuter sur une machine différente pour prendre en compte la latence du réseau ok, c’est bien mon dernier test de résistance. Je fais actuellement ce test sur le même serveur pour déterminer le nombre d’utilisateurs pris en charge avec une latence minimale.

Answer 1

Il n’est pas vraiment clair s’il s’agit d’une application en réseau ou non. S'il est en réseau, vous pouvez simplement faire évoluer le test de résistance en dérobant le bureau de tout le monde pendant le week-end pour exécuter le test de résistance. C’est peut-être le moyen le plus simple d’échelonner le test s’il ne s’agit que de quelques tests ad hoc.

Cependant, il semble que de simples améliorations pourraient être apportées. S'il s'agit d'un long test de résistance, au lieu de créer un nouveau thread pour chaque demande, vous pouvez créer un pool de threads à partir duquel travailler (ou même plus facilement, utilisez le pool de threads, qui sera automatiquement mis à l'échelle). Ainsi, vous définiriez un test comme étant 2000 utilisateurs et allumez 2000 threads qui martèlent le serveur. Chaque thread serait essentiellement dans une boucle qui effectue le test et se répète.

Un autre élément qui n'est pas clair est de savoir si tous vos threads essaient de partager un seul fichier. Une façon de réduire ce goulot d'étranglement serait de conserver les informations en mémoire jusqu'à la fermeture du programme. Ou créez un thread d'écriture, responsable de l'écriture du fichier, et tous vos autres threads lui donnent des informations. Si l'IO est sauvegardé, votre thread d'écriture sera simplement conservé en mémoire jusqu'à ce que l'IO soit disponible, et vos threads de travail pourront continuer à marteler le serveur entre-temps. Gardez simplement à l'esprit qu'en raison de la synchronisation des threads impliquée, la mise à l'échelle de celui-ci risque de ne pas bien s'échelonner. Par conséquent, vous souhaiterez peut-être mettre certaines entrées en mémoire tampon dans le thread de travail et les synchroniser avec le thread d'écriture de fichier toutes les 100 demandes. Je ne pense pas que ce sera un gros problème car il ne semble pas que vous traquiez plus que des temps de réponse.

Edit: Basé sur un commentaire Je suggérerais d'essayer d'utiliser un seul thread pour gérer vos opérations IO dans ce cas. Au lieu d'écrire dans un fichier, tous les threads de travail créeraient un objet avec les détails, et le transféreraient dans une file d'attente pour être écrits dans un fichier. Pour réduire le verrouillage / déverrouillage, utilisez également une file d'attente dans le thread de travail et synchronisez uniquement de temps en temps. Assurez-vous de verrouiller lorsque vous échangez les informations dans le fil. De plus, je regarderais peut-être l'utilisation de la mémoire car cela permettrait à tout ce qui était en attente de s'accumuler en mémoire. Si cela vous empêche toujours de bloquer, j’aimerais envisager d’écrire moins, ou d’accorder ou d’ajouter un disque dur plus rapide.

Answer 2

Si vous êtes intéressé par la latence maximale par utilisateur, pourquoi ne pas simplement la collecter dans le thread et lorsque vous arrêtez le test, demandez à tous les threads d'écrire notre latence maximale. Vous pouvez également faire des statistiques, en calculant min / max / variance et le nombre de threads / utilisateurs en cours d'exécution. Vous ne devriez pas mettre à jour la sortie d'écran non plus. si vous craignez une perte de données, écrivez-les fréquemment sur le disque.

Les threads effectuent ce test de manière sous-optimale pour une application client / serveur. N'ayant qu'un nombre limité de cœurs, très peu de threads fonctionnent réellement en parallèle, mais ont leurs tranches de temps. Il est beaucoup mieux, et vous donne également quelques chiffres sur la latence du réseau, de démarrer votre programme sur plusieurs clients. Le logiciel serveur peut - s’il est capable de le faire - utiliser son matériel comme il le fera dans le réglage final, où les clients fonctionneront sur un réseau local ou étendu.

Évidemment, vous aurez un environnement mixte, car vous ne pouvez pas avoir beaucoup de machines clientes comme le simulent les utilisateurs, mais des scénarios tels que les appels simultanés en provenance de matériel indépendant apparaîtront de manière aussi intense que les appels ne sont pas quasi sérialisés par le biais de la temporisation.