Déterminer une mesure réaliste des demandes par seconde pour un serveur Web

15

J'installe une pile nginx et optimise la configuration avant de passer en direct. En exécutant ab pour tester la tension de la machine, j'ai été déçu de voir les choses dépasser 150 demandes par seconde, un nombre important de demandes prenant plus d'une seconde pour revenir. Curieusement, la machine elle-même ne respirait même pas fort.

J'ai finalement pensé à cingler la boîte et ai vu des temps de cinglement autour de 100-125 ms. (À ma grande surprise, la machine est à travers le pays). Il semble donc que la latence du réseau domine mes tests. Exécution des mêmes tests à partir d'une machine sur le même réseau que le serveur (temps de ping <1 ms) et je vois> 5000 requêtes par seconde, ce qui est plus en ligne avec ce que j'attendais de la machine.

Mais cela m'a fait réfléchir: comment puis-je déterminer et signaler une mesure "réaliste" des demandes par seconde pour un serveur Web? Vous voyez toujours des affirmations sur les performances, mais la latence du réseau ne doit-elle pas être prise en compte? Bien sûr, je peux servir 5000 requêtes par seconde à une machine à côté du serveur, mais pas à une machine à travers le pays. Si j'ai beaucoup de connexions lentes, elles auront éventuellement un impact sur les performances de mon serveur, non? Ou est-ce que je pense à tout cela de travers?

Pardonnez-moi si c'est de l'ingénierie de réseau 101. Je suis développeur de métier.

Mise à jour: édité pour plus de clarté.

— Don
source

aba une option d'accès simultané. À quoi l'avez-vous réglé? De plus, si vous testez à partir d'une connexion ADSL domestique, le test sera probablement dominé par votre bande passante et ne testera rien du tout sur le serveur.

— Ladadadada

Je connais l'option de simultanéité de ab et j'ai essayé un large éventail de valeurs pour découvrir les limites de la boîte. Comme je l'ai écrit ci-dessus, je comprends que mes tests initiaux étaient dominés par le réseau et ne reflétaient pas la capacité du serveur. Mais ma question demeure: d'où la plupart des gens exécutent-ils leurs tests pour obtenir des mesures réalistes? Les tests exécutés à partir d'une boîte sur le même réseau que le serveur (supprimant efficacement toute latence du réseau de l'équation) renvoient de grands nombres, mais ils ne semblent pas être des chiffres "justes" car les vrais utilisateurs proviendront de l'extérieur du réseau.

— Don

Les tests exécutés à partir du même réseau peuvent en fait être plus «équitables» car ils ignorent essentiellement le réseau. Vos utilisateurs sont probablement tous sur des réseaux différents - donc la bande passante agrégée de tous ces réseaux devrait facilement dépasser la bande passante disponible de votre serveur. En considérant tous les utilisateurs ensemble, le goulot d'étranglement est donc les capacités du serveur - alors qu'en considérant un utilisateur individuel, le goulot d'étranglement peut être la bande passante de cet utilisateur unique. (Le test idéal, peut-être, serait exécuté à partir de plusieurs emplacements distants pour simuler au mieux les circonstances réelles, bien que la plupart des cas ne devraient pas en avoir besoin).

— cyberx86

"En considérant tous les utilisateurs ensemble, le goulot d'étranglement est donc les capacités du serveur" - cela a du sens et semble être la bonne façon d'y penser. Je suppose que le serveur pourrait être assis derrière un équipement réseau merdique, limitant son taux de réponse au monde extérieur, mais ce n'est pas vraiment le problème du serveur et doit être traité séparément. Quelque chose comme Pingdom pourrait être utilisé pour exécuter le test idéal, je suppose.

— Don

3

Si vous vous souciez des performances de votre serveur lorsque vous y accédez depuis quelque part dans le monde, demandez à un ami quelque part dans le monde (devrait avoir une bonne bande passante) d'installer sproxy + siege sur sa boîte Linux. Téléchargez, configurez, créez. Ces outils sont petits, ils se compilent en quelques secondes.

Tout d'abord, commencez sproxysur la boîte Linux. Par défaut, il s'exécutera sur le port 9001 sur localhost (127.0.0.1). Si vous souhaitez y accéder de l'extérieur, passez-lui simplement l'adresse IP sortante comme paramètre.
Connectez-vous maintenant à sproxy en configurant votre navigateur pour utiliser cette adresse IP et ce port comme proxy pour HTTP. Tout ce que vous faites désormais est enregistré par sproxy et peut être rejoué ultérieurement. Maintenant, surfez sur votre site, faites ce que vos clients feraient et essayez de faire des choses "chères" qui utilisent votre serveur.
Une fois terminé, terminez sproxy en appuyant sur CTRL ^ C. Il a enregistré vos actions $HOME/urls.txt. Déplacez le fichier là où réside le siège. Pour commencer les tests de résistance, exécutez siege -f urls.txt -d NUM -c NUM. dreprésente le délai entre les demandes, lorsque vous effectuez des tests de performances, utilisez 1 (seconde).creprésente le nombre d'utilisateurs simultanés simulés. Choisissez à volonté, mais commencez bas. Siege vous montrera le nombre de transactions par seconde, le taux d'erreur, la durée moyenne des requêtes, etc. C'est un outil puissant et facile à utiliser.
Si vous avez besoin de plus d' informations sur les paramètres (il y a beaucoup), vérifiez le siège manuel un du manuel sProxy

Pour obtenir des résultats plus réalistes, laissez de nombreuses personnes tester votre serveur de différents pays à la fois et laissez-les vous envoyer les statistiques.

— SebiF
source

2

La mesure réaliste des requêtes / s doit être prise dans les journaux d'accès. OMI, la latence des demandes n'a rien à voir avec la charge du serveur, car le serveur traite toutes les demandes à la même vitesse, quelle que soit leur origine.

— ejaenv
source

1

Pensez à utiliser des services tels que Soasta Cloudtest . Avec lui, vous pouvez obtenir des rapports assez détaillés sur vos tests et vous pouvez exécuter des tests de performances à partir de divers fournisseurs de cloud public / virtualisation. Vous pouvez configurer la force et la durée de martelage de vos serveurs. Ils ont également une version gratuite " lite " afin que vous puissiez voir ce que cela peut faire avant d'engager de l'argent.

— Mxx
source