Quelle est la précision des tests avec le Siège et l'AB?

Je suis curieux de savoir combien je peux compter sur les résultats de tests de charge avec Siège et AB. Je me rends compte qu'ils ne prennent pas statique des actifs en compte (images, JS, CSS), mais en supposant que tout ça est servi à partir d'un CDN, si le Siège/AB me dit que je peux répondre à 200 utilisateurs simultanés, est-il une raison que je ne devrais pas confiance en elle? Je ne suis pas à l'examen d'autres facteurs, tels que les limitations de la machine exécutant le test peut-être?

InformationsquelleAutor Matt Fordham | 2012-12-11
  1. 35

    Voici un très bon article qui explique les pièges d'essayer de faire Siege ou ab essais de type et ensuite résumé de la façon dont votre application ou site web va travailler sous la charge.

    http://www.sonassi.com/knowledge-base/magento-kb/why-siege-isnt-an-accurate-test-tool-for-magento-performance/

    Voici quelques balles à partir de cette page amener des problèmes avec ce type de tests:

    • Siège n'est pas représentative de ce qu'un utilisateur réel (ou plusieurs utilisateurs) serait effectivement en train de faire sur votre site web. Il ne peut charger que le raw code de réponse et HTML, pas tous les autres éléments à l'intérieur d'une page (images, CSS, JS ou autre contenu statique) – donc, effectivement, il ne teste que des performances de PHP.

    • Il a aussi très limitée de la séance/le support des cookies, pas de support pour le pipelining et de support de base pour le protocole HTTP/1.1. La charge c'est la génération est rien de tel que d'un réel de l'utilisateur, de sorte que, tandis que ses bon pour une référence rapide après les modifications; il n'a pas vraiment d'indiquer que quelque chose va changer pour l'utilisateur dans la vie réelle.

    • Siège est facile à berner, il ne peut pas faire la différence entre un fichier statique servi (ie. un fichier HTML) ou dynamique (fichier ie. une dynamique Magento PHP de la page). Donc, si vous exécutez n'importe quel type de fichier statique proxy, les résultats sont immédiatement biaisée. À ce point – la, vous ne serez qu'à tester le proxy cache, pas la vitesse de livraison derrière elle.

    • De sorte que ceux utilisant le Vernis, Nginx la mise en cache, mod_pagecache pouvez facilement juste tampon de la page en cache et vous verrez sous 20ms les temps de rendu. Si votre utilisation de Vernis, puis à l'aide de Siège de test de performance – vous pourriez aussi bien être le chargement d'une image plutôt que de la catégorie de l'URL, comme il va donner les mêmes résultats.

    • Test des serveurs distants est presque inutile, car c'est une simultanéité de test (c'est à dire. combien de demandes peuvent être satisfaites à plusieurs reprises), le goulot d'étranglement est la connexion réseau entre les deux machines. Temps de latence et le protocole TCP/IP, les frais généraux sont ce qui rend le test d'un site distant complètement inutile, la moindre encombrement du réseau entre pairs entre les deux serveurs seront immédiatement apparaître une baisse de la performance. Donc, ce qui commence vraiment à entrer en jeu, c'est la rapidité de la TCP 3-way handshake peut être complété – le serveur testé pourrait être en train de servir une page dynamique ou statique fichier de 0 octet – et vous pouvez voir exactement les mêmes taux de rendement, comme la connectivité est le goulot d'étranglement.

    L'autre problème qu'ils ont à discuter dans l'article, qui peut avoir le plus d'impact dramatique sur votre site web à la performance globale est le temps de latence entre votre site et les clients qui y accèdent. Ils ont une bonne explication de la façon dont la latence peut influer sur les performances de vos sites dans les moyens que vos utilisateurs vont le sentir, mais Siege et ab type de test des outils n'exposez jamais.

    Nouveau extraction de l'article:

    Ping à partir de royaume-UNI au royaume-UNI

    [~]$ ping www.bytemark.co.uk -c4
PING www.bytemark.co.uk (212.110.161.177) 56(84) bytes of data.
64 bytes from extapp-front.bytemark.co.uk (212.110.161.177): icmp_seq=1 ttl=57 time=2.86 ms
64 bytes from extapp-front.bytemark.co.uk (212.110.161.177): icmp_seq=2 ttl=57 time=2.51 ms
64 bytes from extapp-front.bytemark.co.uk (212.110.161.177): icmp_seq=3 ttl=57 time=2.54 ms
64 bytes from extapp-front.bytemark.co.uk (212.110.161.177): icmp_seq=4 ttl=57 time=2.63 ms
--- www.bytemark.co.uk ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 2.515/2.641/2.869/0.142 ms

    Ping à partir de royaume-UNI vers les etats-unis

    [~]$ ping www.mediatemple.net -c 4
PING www.mediatemple.net (64.207.129.182) 56(84) bytes of data.
64 bytes from mediatemple.net (64.207.129.182): icmp_seq=1 ttl=49 time=158 ms
64 bytes from mediatemple.net (64.207.129.182): icmp_seq=2 ttl=49 time=154 ms
64 bytes from mediatemple.net (64.207.129.182): icmp_seq=3 ttl=49 time=154 ms
64 bytes from mediatemple.net (64.207.129.182): icmp_seq=4 ttl=49 time=154 ms

--- www.mediatemple.net ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 154.155/155.282/158.321/1.802 ms

    Vous pouvez voir immédiatement la différence dans les performances. Pour cette seule
    Connexion TCP/IP vers les états-unis à partir du royaume-UNI, il a fallu 156ms, 62 fois plus
    que pour un serveur dans le royaume-UNI. Ce qui signifie qu'avant même de tenter
    quoi que ce soit, le débit maximal que vous pouvez obtenir sur l'état de Siège dans un deuxième
    va être autour de 6 opérations par seconde, en raison de la latence seul.

    Je vous suggère fortement de lire l'article en entier. Il fait un très bon travail d'expliquer les pièges de faire des tests de performances en utilisant des outils tels que Siege et ab!

    • je ne pense pas que l'article fait remarquer correctement les tests de télécommandes, oui c'est vrai il y a plus de latence, mais si vous faites un (charge) des tests en parallèle vous "payé qu'une seule fois" en une seconde.
    InformationsquelleAutor slm