Wie genau ist die Prüfung mit Belagerung und AB?

Ich bin neugierig zu wissen, wie viel kann ich darauf Vertrauen, dass die Ergebnisse der Lasttests mit Belagerung und AB. Ich weiß, dass Sie nehmen Sie nicht die statischen Elemente zu berücksichtigen sind (Bilder, JS, CSS), aber unter der Annahme, dass alle Sachen serviert von einem CDN aus, wenn die Belagerung/AB-sagt mir, ich kann gerecht zu 200 gleichzeitige Benutzer, gibt es einen Grund sollte ich nicht Vertrauen? Bin ich nicht und berücksichtigt keine anderen Faktoren, wie Einschränkungen der Maschine läuft der test kann?

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

    Hier ist ein ziemlich guter Artikel, der beschreibt die Fallstricke versuchen, das zu tun Siege oder ab - Typ testen und dann Abstrakt, wie gut Ihre webapp oder website durchführen unter Last.

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

    Hier sind einige Kugeln aus, die Seite, dass die Probleme mit dem zu tun, diese Art von Tests:

    • Belagerung ist nicht repräsentativ für das, was ein real-Benutzer (oder mehrere Benutzer) wäre eigentlich auf Ihrer website. Es kann nur laden Sie die raw-Antwort-code und HTML, nicht auf alle anderen Elemente innerhalb einer Seite (Bilder, CSS, JS oder andere statische Inhalte) – so effektiv, dass es nur tests, die PHP-performance.

    • Es hat auch sehr begrenzte session - /cookie-Unterstützung, keine Unterstützung für pipelining und grundlegende Unterstützung für HTTP/1.1. Der laden ist die Erzeugung ist nichts anderes wie das ein real-user, also während dessen gut für eine schnelle Referenz nach Veränderungen; es ist nicht wirklich zeigen, dass alles, was wird sich ändern für einen Benutzer im wirklichen Leben.

    • Belagerung ist leicht zu täuschen, es kann nicht unterscheiden zwischen einer statischen Datei bedient (dh. eine Reine HTML-Datei) oder eine dynamische Datei (dh. eine dynamische Magento PHP-Seite). Also, wenn Sie unter jeder Art von statischen Datei-proxy, die Ergebnisse sind sofort verzerrt. An dieser Stelle werden Ihnen nur die Prüfung der caching-proxy, die nicht am Liefergegenstand speed dahinter.

    • Also diejenigen, die sich mit Varnish, Nginx-caching, mod_pagecache kann einfach nur Puffer, die Seite in einen cache und du wirst sehen, sub 20ms rendering-Zeiten. Wenn Ihr mit Lack, dann mit Belagerung Leistung zu testen – Sie könnte genauso gut sein, das laden eines Bildes anstelle der Kategorie-URL, es gebe die exakt gleichen Ergebnisse.

    • Testen von remote-Servern ist fast sinnlos, da es eine Parallelität test (dh. wie viele Wünsche können erfüllt werden wiederholt), die unmittelbaren Engpass ist die Netzwerkverbindung zwischen den beiden Rechnern. Latenz und TCP/IP-overheads sind, was das testen einer remote-site, völlig sinnlos, die geringste überlastung des Netzwerks unter einem peer zwischen den beiden Servern wird sofort reduziert die Leistung. Also, was beginnt wirklich ins Spiel kommen, ist, wie schnell die TCP-3-Wege-handshake abgeschlossen werden kann – der server getestet werden könnte, serviert eine dynamische Seite oder eine statische 0-byte-Datei – und Sie konnte sehen, genau das gleiche raten von der Leistung, Konnektivität ist der Engpass.

    Die andere Frage, die Sie diskutieren in dem Artikel haben die meisten dramatischen Einfluss auf Ihre website Gesamtleistung ist die Latenz zwischen Ihrer Website und der clients, die Zugriff auf Sie. Sie haben eine gute Erklärung dafür, wie die Latenz kann sich auf Ihre Websites die Leistung in einer Weise, dass Ihre end-Nutzer fühlen es aber Siege und ab Art von testing-tools setzen Sie niemals.

    Wieder excerpting den Artikel:

    Ping von UK zu UK

    [~]$ 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 von Großbritannien in die USA

    [~]$ 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

    Können Sie sehen sofort den Unterschied in der Leistung. Die single
    TCP/IP-Verbindung zu den USA aus dem Vereinigten Königreich, dauerte es 156ms, 62 mal mehr
    als zu einem server in Großbritannien. Das bedeutet, dass, bevor Sie sogar versuchen,
    alles andere, ist der maximale Durchsatz, den Sie erzielen können, auf die Belagerung in eine zweite
    werde auf etwa 6 Transaktionen pro Sekunde, aufgrund der Latenz alleine.

    Ich sehr empfehlen, Lesen Sie den gesamten Artikel. Es hat einen sehr guten job zu erklären, die Fallstricke zu tun, performance-Tests mit tools wie Siege und ab!

    • ich glaube nicht, dass der Artikel darauf hingewiesen, korrekt testen von Fernbedienungen", ja, es ist wahr es ist mehr Latenz, aber wenn Sie ein (Last -) tests parallel Sie "nur einmal gezahlt" in einem zweiten.
    InformationsquelleAutor slm
Schreibe einen Kommentar