problème jmeter multiples utilisateurs

Question

Nous utilisons Jmeter pour tester notre application Php en cours d'exécution sur le serveur Web Apache 2. Je peux charger Jmeter utiliser 25 ou 50 fils et la charge sur le serveur n'augmente cependant pas le temps de réponse du serveur fait. Les plusieurs fils le plus lent, le temps de réponse. Il semble que Jmeter ou Apache est en file d'attente les demandes. J'ai changé la valeur maxclients dans le fichier de configuration du serveur web apache, mais cela ne change pas le problème. Alors que Jmeter est en cours d'exécution, je peux utiliser l'application et obtenir des temps de réponse respectables. Ce qui donne? Je pense être en mesure d'imposer mon serveur à 0% au ralenti par augmenter le nombre de threads. Quelqu'un peut-il aider à me diriger dans la bonne direction?

Mise à jour: Je trouve que si je retire des sessions de mon application, je suis en mesure de simuler une pleine charge sur le serveur. J'ai essayé de réactiver des sessions et d'utiliser un gestionnaire de cookies HTTP pour chaque thread, mais il ne semble pas avoir un impact.

Answer 1

Vous devez identifier où le goulot d'étranglement se produit, et ensuite tenter de corriger le problème.

• Le client JMeter doit être exécuté sur une machine bien equipted. Je préfère un serveur Solaris / Unix exécutant la machine virtuelle Java, mais pour <200 fils, une machine windows moderne fera très bien. JMeter peut devenir un goulot d'étranglement, et vous n'obtenir des résultats significatifs une fois qu'il fait. En outre, il devrait fonctionner sur une machine distincte à ce que vos tests, et de préférence sur le même réseau. La latence WAN peut devenir un problème si votre plate-forme de test et le serveur sont éloignés.
• La deuxième chose à vérifier est votre personnel Apache. Apache a un module - mod_status - qui vous montrera l'état de chaque travailleur. Il est possible d'avoir la taille de votre piscine trop bas. De l'mod_status, vous serez en mesure de voir combien de travailleurs sont en cours d'utilisation. Pour quelques-uns, et Apache aucun travailleur pour traiter les demandes et les demandes en file d'attente vers le haut. Un trop grand nombre, et Apache peut épuiser la mémoire sur la boîte, il fonctionne sur.
• Ensuite, vous devriez vérifier votre base de données. S'il est sur une autre machine, la base de données pourrait avoir une IO ou la pénurie de CPU.
• Si votre frappais un goulot d'étranglement, et le serveur et db sont sur la même machine, vous généralement frappé une CPU, RAM, ou limite IO. J'énuméré ceux dans l'ordre dans lequel ils sont plus faciles à identifier. Si vous obtenez une application liée CPU, vous pouvez facilement vous voir l'utilisation du processeur aller à 100%. Si vous manquez de RAM, votre machine va commencer la permutation. Sur Windows et unix, il est assez facile de voir votre RAM disponible. Enfin, vous pouvez être IO lié. Cela peut aussi être contrôlée à l'aide de différents outils ou statistiques, mais il est pas aussi évident que le processeur.

Enfin, plus précisément à votre question, la seule chose qui se démarque est il est possible d'avoir un grand nombre de fichiers de session stockés dans un seul répertoire. Souvent stocke les informations de session PHP dans les fichiers. Si ce répertoire devient grand, il faudra de plus en plus longue quantité de temps pour PHP pour trouver la session. Si vous avez exécuté votre test désactivé les cookies, l'application PHP peut avoir créé des milliers de fichiers de session pour chaque demande de l'utilisateur. Sur un serveur Windows, il va ralentir plus vite que sur un serveur unix, faire des différences dans les répertoires de manière sont stockés sur les deux systèmes d'exploitation.

Answer 2

Utilisez-vous un compte à débit constant? Si Jmeter ne peut pas servir le débit avec les fils qui lui sont attribués, vous verrez ce faire la queue et les éruptions dans le temps de réponse. Pour savoir si tel est le problème, essayez d'ajouter plusieurs threads.

J'ai aussi trouvé un rapport de ce qui se passe quand il y a des appels JavaScript dans le script. Dans ce cas, essayez de passer des appels JavaScript à l'élément de plan de test en haut du script, ou chercher des moyens de pré-calcul de la valeur.

Answer 3

Essayez de vérifier un fichier statique servi par apache et non par PHP pour voir si le problème est dans la configuration Apache ou la configuration de PHP.

Vérifiez également les connexions réseau et la configuration. Nos tests JMeter progressait bien jusqu'à ce qu'il frappe un mur. Finalement réalisé que nous avions seulement une connexion 100Mb et il a été saturé, va gigabit fixe elle. Les cartes réseau ou commutateur peut être en cours d'exécution à une vitesse plus faible que vous pensez, surtout si leur réglage de la vitesse est « auto ».