Freunde, guten Tag!
Wir setzen die Reihe der Veröffentlichungen „ohne Kürzungen“ über entwicklungsbezogene Projekte fort, häufig mit dem Präfix „Web“. Lassen Sie uns heute über Stresstests sprechen. Das Problem ist, dass oft weder der Kunde noch der Projektmanager verstehen, warum es benötigt wird, welche Risiken es reduzieren kann, wie es zu organisieren ist und wie und dies meiner Meinung nach schwierig ist, seine Ergebnisse zum Nutzen des Unternehmens zu interpretieren. Wir gießen Kaffee ein und lass uns gehen ...
Warum sollte ein Webprojekt geladen werden?
Tatsache ist, dass während in einigen Webprojekten noch Selbsttests geschrieben werden, um die Qualität aufrechtzuerhalten, nur wenige Personen in der Entwicklungsphase an der Leistungskontrolle beteiligt sind. Es ist sehr selten, dass ein Webprojekt sowohl Autotests als auch Code-Benchmarks enthält. Häufiger und aus vernünftigen Gründen werden bei der Entwicklung folgende Heuristiken eingehalten, die ein gutes Nutzen-Kosten-Verhältnis aufweisen:
- Abfragen an MySQL (wir werden diese beliebte Datenbank als Beispiel verwenden) durchlaufen eine ziemlich angemessene API, die Indizes verwendet (obwohl wir nicht sehen, wie genau die Indizes vom Scheduler verwendet werden, wie hoch ihre Kardinalität ist).
- Ergebnisse der Ausführung von Datenbankabfragen und umfangreichen Codeteilen werden zwischengespeichert
- Der Entwickler hat 3.14 Mal die Erstellung der Webseite im Browser überprüft. Wenn das Auge dadurch nicht verlangsamt wird, ist alles in Ordnung
Heuristiken funktionieren oft gut, aber je größer und schwerer das Projekt ist, desto
mehr kann mit exponentiell zunehmender Wahrscheinlichkeit etwas
schief gehen .
Nehmen Sie das Caching. Bei der Entwicklung bleibt oft keine Zeit darüber nachzudenken, wie oft der Cache neu erstellt werden kann. Aber vergebens. Wenn das Wiederherstellen eines Caches, beispielsweise eines Produktkatalogs, lange dauert und der Cache beim Hinzufügen eines Produkts zurückgesetzt wird, kann das Zwischenspeichern mehr schaden als nützen.
Aus diesem Grund wird übrigens nicht empfohlen, den integrierten MySQL-Abfragecache zu verwenden, der unter einem ähnlichen Problem leidet: Wenn Sie mindestens einen Tabellendatensatz ändern, wird der Tabellencache vollständig zurückgesetzt (stellen Sie sich eine Tabelle mit 100.000 Zeilen vor und die Absurdität der Situation wird offensichtlich).
Eine ähnliche Situation bei MySQL-Abfragen. Wenn Abfragen von Indizes ausgeführt werden, werden Abfragen im Allgemeinen ausgeführt ... "schneller". Sie können davon ausgehen, dass die Ausführungszeit solcher Abfragen logarithmisch von der Datenmenge abhängt (O (log (n))). In der Praxis stellt sich jedoch häufig heraus, dass einige Abfragen andere betreffen und gleichzeitig die allgemeinen Subsysteme der Datenbank verwenden (Sortieren auf einer Festplatte, die langsamer wird), und Sie können dies nicht sofort vorhersagen.
Außerdem werden beim Laden häufig interessante Funktionen des Betriebssystems festgestellt, insbesondere ein Überlauf des Bereichs ausgehender TCP / IP-Client-Ports während der intensiven Arbeit mit Memcached. Oder Apache wird mit Anfragen zur Bildverarbeitung verstopft, weil Während der Konfiguration haben sie vergessen, ihre Verarbeitung durch den Nginx-Caching-Proxy-Server zu konfigurieren.
Manchmal vergessen sie, in MySQL den Pfad für temporäre Tabellen auf einer Festplatte zu installieren, die Daten dem RAM zuordnet ("/ dev / shm"). Aus diesem Grund legt der Datenbankserver bei zunehmender Auslastung intensive Sortierungen fest.
Wenn dem Webprojekt Daten hinzugefügt werden, zeigen Abfragen und Algorithmen in einem Volume in der Nähe des Kampfprojekts aggressiv ihre „O-Notation“ an: Wenn der Kartesier für eine kleine Datenmenge unsichtbar ist, wird der Datenbankserver aufgrund der Spannung rot, wenn das Kampfvolumen angezeigt wird.
Es gibt noch viele weitere Beispiele. Lassen Sie uns zunächst darauf eingehen. Das Wichtigste zu verstehen ist, dass Lasttests notwendig sind. Weil es sehr teuer, sehr lang und wirtschaftlich unpraktisch ist, alle möglichen Optionen zum „Bremsen“ eines mittelgroßen Websystems im Voraus vorauszusehen.
Wie identifiziere ich Stresstestziele?
Hier ist es wichtig zu verstehen, was Ihnen und dem Kunden tatsächlich das Qualitätsniveau des Websystems während Stresstests zeigt. Es gibt nichts Besseres als konkrete Beispiele für gute und schlechte Stresstestziele:
- 1 Million Treffer gemacht. Durchschnittliche Erstellungszeit der Webseite = 1 Sek. Was zeigt das? Nichts. Wie lange dauerte der Lasttest? Die Ausführungszeit einer einzelnen Anforderung kann entweder 1 ms oder 600 Sekunden betragen, und es ist unklar, welche Anteile größer sind. Und wie viele Fehler es gab (die Nginx-Antwort im Stil von "Fehler 50x") ist auch nicht klar :-)
- 1 Million Treffer gemacht. Mittlere Erstellungszeit der Webseite = 1 Sek., Die Anzahl der HTTP-Fehler beträgt 0,5%. Was zeigt dies? Bisher ein wenig nützlich, aber besser. Wir wissen bereits, dass der Anteil der unzureichenden Fehler, die der Kunde feststellen kann, großartig ist, und Sie können mit der Vorbereitung beginnen und in die Apotheke gehen. Der Median ist eine Metrik, die gegenüber „Ausreißern“ widerstandsfähiger ist als der Durchschnitt (robustere Schätzung), daher ist sie zweifellos besser als der arithmetische Durchschnitt. Aber lassen Sie uns die Metriken noch nützlicher machen.
- Pro Tag wurden 1 Million Treffer erzielt. 25% der Treffer wurden in weniger als 10 ms erzielt, 50% der Treffer wurden in weniger als 1 Sekunde erzielt (dies ist der Median oder das 50-Perzentil), 75% der Treffer wurden in weniger als 1,5 Sekunden erzielt, 95% der Treffer wurden in weniger als 1 Sekunde erzielt 5 Sek. Und die Anzahl der HTTP-Fehler beträgt 0,5%. Das war's! Wir sehen den Anteil unzureichender Fehler, die der Client abfangen kann, aber wir sehen auch den Anteil der Anforderungen, die über einem bestimmten Schwellenwert ausgeführt werden.
Wie Sie sehen können, ist die Auswahl geeigneter Metriken zur Beurteilung der Geschwindigkeit eines Webprojekts während des Lasttests sehr, sehr wichtig. Es gibt nur ein Prinzip: Metriken sollten sowohl für den Kunden als auch für Sie absolut klar sein und die Qualität gut und klar zeigen. Tatsächlich ist die offensichtlichste und korrekteste Metrik die Verteilung der Trefferverarbeitungsgeschwindigkeit über die Zeit. Wenn es Ihnen bei Ihren Stresstests gelingt, wird dies super. Darüber hinaus können Sie 2 Stresstests anhand der Verteilung der Zeittreffer vergleichen und sehen, wie und wo sie besser wurden. Visualisierung ist Macht!
Nichts ist klar: Perzentile, Mediane, Quantile, Entwürfe, Verteilung ...
Alles ist einfach! Jetzt werde ich in einer wunderschönen Umgebung für die Datenanalyse zeichnen und zeigen: Jupyter Notebook / Python.
Angenommen, innerhalb von Millisekunden wurden 10 Zugriffe auf die Website ausgeführt:
Sortieren Sie nun die Zeit, die benötigt wird, um die Treffer in aufsteigender Reihenfolge zu vervollständigen:
Wir sind einen Schritt vom Verständnis des Medians, des 25. und 75. Perzentels entfernt. Alles ist einfach - wir teilen das Diagramm in zwei Hälften und in der Mitte befindet sich ein „Median“ (Nummer 1 auf dem Diagramm). Das erste Quartal des Diagramms entspricht dem 25. Perzentil (Nummer 2 im Diagramm) und das dritte Quartal entspricht dem 75. Perzentil (Nummer 3 im Diagramm). Dementsprechend werden andere Perzentile erhalten (oder, wie sie auch Quantile genannt werden) - 90, 95, 99 usw.:
Und es sieht aus wie die Verteilung (Histogramm) über die Ausführungszeit der oben genannten Treffer. Wie Sie sehen, ist alles sehr klar und einfach:
Auf diese Weise können Sie schnell eine Verteilung (Histogramm) erstellen, die auf dem Anforderungsprotokoll für Lasttests basiert. Ändern Sie Ihr Protokollformat:
Und du bekommst so etwas:
Ich hoffe jetzt ist alles klar und in Ordnung. Wenn nicht, fragen Sie in den Kommentaren.
Stresstestzeit
Oft wird gefragt, wie lange der Auslastungstest eines Webprojekts dauern soll. Es gibt eine einfache Heuristik: Im Betriebssystem werden geplante Aufgaben häufig einmal am Tag ausgeführt: Sicherungen, Rotation von Protokollen usw. Daher sollte die Zeit für die Durchführung von Lasttests nicht weniger als korrekte Tage betragen. Wenn das Webprojekt auf Bitrix basiert, hat die Plattform auch viele geplante Aufgaben und es ist ratsam, das Web-System mindestens einen Tag lang zu laden.
Lastausgleich
Wenn Sie bereits eine betriebene Website haben, können Sie von dort aus die Besuchsprotokolle abrufen und das neue Websystem damit laden. Oft lösen sie jedoch das Problem, nur das entwickelte Websystem zu laden. Für die Planung des Lastausgleichs eignet sich häufig das Modell der Aufteilung potenzieller Ketten von Ortsbesichtigungen in Anteile. Zum Beispiel:
- Home - News - Detaillierte News = 50%
- Home - Katalogübersicht - Detaillierter Katalog = 30%
- Detaillierter Katalog - Katalogübersicht - Detaillierter Katalog = 15%
- Suchergebnisse - Detaillierter Katalog = 5%
In der Software zum Erstellen einer Last (wir verwenden häufig Jmeter) werden für jede Kette so viele Lastflüsse erstellt, dass unter Berücksichtigung des Intervalls zwischen den Treffern in der Kette die Gesamtzahl der Treffer jeder Kette pro Zeiteinheit wie folgt korreliert wird: 50%, 30%, 15%, 5% .
Die Berechnung von Intervallen und Lastflüssen ist in Excel oder auf einem Blatt mit einem Bleistift einfach.
Lastkettenstruktur
Es ist wichtig, die Merkmale des Lebenszyklus des Benutzers des Websystems zu berücksichtigen. Oft melden sich Benutzer an und gehen dann zur Website. Dazu müssen Sie die Aktionen, die zur Autorisierung führen, am Anfang der Lastkette platzieren:
Dem Pferd ist klar, dass es unmöglich ist, während Stresstests nur eine detaillierte Seite des Katalogs abzurufen. Daher ist es nützlich, die Liste aus der CSV-Datei zu lesen und zu drehen:
Zwischen den Treffern müssen Sie natürlich zufällige Pausen einlegen, damit wir der Last, die von echten Benutzern erzeugt wird, näher kommen. Vergessen Sie nicht, Cookie-Werte zu speichern und an den Server zurückzugeben:
Die globalen Variablen von Lastketten, einschließlich der Anzahl der Threads, sind einfach zu konfigurieren. Bestimmte globale Variablen können dann an verschiedenen Stellen in den Lastketten verwendet werden:
Wie kann man Stresstests sicher beenden?
In der Praxis stürzt das Testen der Last in den ersten Minuten oder Stunden fast immer ab, alles beginnt zu rauchen, brennt dann, die Site öffnet sich nicht, MySQL fällt in einen Tausch und erlaubt sich nicht, eine Verbindung herzustellen, LA auf Servern nähert sich 100, Entwickler beginnen zu laufen mit den Worten "das hätte nicht passieren dürfen" und Sysadmins mit einem Grinsen antworten normalerweise "es gibt Gerechtigkeit im Leben!" und fang an, Bier im Serverraum zu trinken.
Um zu verstehen, warum alles heruntergefallen ist und was repariert werden muss, um dem Kunden die Ergebnisse eines „erfolgreichen“ Lasttests an einem Tag zu zeigen, müssen Sie zunächst die Aufzeichnung der wichtigsten Lebensdaten des Betriebssystems aktivieren - dies ist bei den kostenlosen Munun / Cacti-Produkten einfach.
Ich werde auflisten, was während des Zusammenbruchs eines Websystems am häufigsten passiert und wie dies behoben werden kann.
Zunächst wird der Apache- oder PHP-Fpm-Webserver mit Anfragen "verstopft":
Meistens geschieht dies aufgrund des Zusammenbruchs von MySQL - die Anzahl der hängenden Abfrageflüsse nimmt zu:
Was ist der Grund dafür? Oft vergessen sie von oben, die Anzahl der Apache- oder Abfrageflüsse auf MySQL zu beschränken, was dazu führt, dass Anwendungen aus dem RAM in einen langsamen Austausch mit Krämpfen fallen:
Hier können Sie die plötzliche Aktivität bei der Arbeit mit einem Tausch sehen. Sie müssen verstehen, wer in den Tausch gefallen ist und wo:
Manchmal liegt das Problem jedoch auf der Seite des langsamen Festplattensubsystems. In diesem Fall steigt LA stark an und der Prozentsatz der Festplattenauslastung nähert sich 100 (Grafik unten rechts):
Offensichtlich habe ich nur einen Teil des Interessantesten enthüllt, das mit einem Webprojekt während Stresstests beginnen kann. Die Hauptsache ist jedoch, die richtige Richtung festzulegen und den richtigen Prozess aufzubauen. Fragen Sie in den Kommentaren, was während des Ladens aufgetaucht ist, ich werde versuchen zu helfen.
Interpretation der Stresstestergebnisse
Normalerweise beginnt der Lasttest nach 5-10 Neustarts und Anpassungen mit dem Flug und wird erfolgreich abgeschlossen. Daher sollten Sie ungefähr eine Reihe dieser Protokolle zur weiteren Analyse haben:
- Protokoll der Anforderungen an nginx mit dem Zeitpunkt der Clientanforderung (in diesem Fall wird die Software geladen), der Proxy-Zeit von nginx an apache / php-fpm
- Nginx-Fehlerprotokoll
- Apache / PHP-Fpm-Anforderungsprotokoll mit Anforderungsverarbeitungszeit und HTTP-Antwortstatus
- apache / php-fpm fehlerprotokoll
- MySQL Slow Log
- MySQL-Fehlerprotokoll
Darüber hinaus sollten am vergangenen Tag analytische Diagramme zur Verwendung von CPU, Festplatten, MySQL, RAM, Apache-Workern usw. erstellt werden. (siehe obige Beispiele für Munin-Diagramme).
Mit diesen Artefakten können Sie mithilfe eines einfachen awk-Skripts am Anfang des Beitrags Verteilungen (Histogramme) über diese Protokolle erstellen und die Anzahl und Art der HTTP-Fehler berechnen. In der Tat können Sie einen Bericht über den Erfolg von Stresstests über diesen Inhalt erstellen, der sehr umfangreich und nützlich für Unternehmen und Entscheidungen ist:
Während des Tages machte 1 Million Treffer. 25% der Treffer wurden in weniger als 50 ms erzielt, 50% der Treffer wurden in weniger als 0,5 Sekunden (Median) erzielt, 75% der Treffer wurden in weniger als 1 Sekunde ausgeführt, 95% der Treffer wurden in weniger als 5 Sekunden ausgeführt, die Anzahl der HTTP-Fehler - 0,01%. Testdaten: Katalog, Benutzer, Nachrichten, Artikel wurden in einem Volumen überflutet, das dem erwarteten nahe kam. Ein Entwickler hat sich selbst erschossen.
Lastketten:
Home - News - Detaillierte News = 50%
Home - Katalogübersicht - Detaillierter Katalog = 30%
Detaillierter Katalog - Katalogübersicht - Detaillierter Katalog = 15%
Suchergebnisse - Detaillierter Katalog = 5%
Diagramme zur Verwendung von Serverressourcen:
...
Dies ist ein guter und verständlicher Bericht über die Lasttests des Websystems. Für Liebhaber akuter Schmerzen können Sie während des Belastungstests weiterhin empfehlen, jede Minute den Import / Export von Daten aus Systemen der Klassen SAP, 1C usw. auf eine Website einzuschließen. und synchrone Verbindungen über TCP / IP-Sockets mit externen Austauschdiensten, beispielsweise Kryptowährungen :-)
Aber um ehrlich zu sein, wenn Import-Export sorgfältig und ehrlich durchgeführt wird, zeigen Lasttests und unter solchen Bedingungen akzeptable Zahlen für das Geschäft.
Woher kommen Stresstests?
Übrigens, ja, wir haben diesen Moment nicht hervorgehoben. Aus trivialen Gründen tritt normalerweise das mangelnde Gleichgewicht zwischen Nginx-Apache-MySQL-Mitarbeitern auf. Das heißt, Die Anzahl der Worker ist nicht von oben beschränkt. Infolgedessen können 500 Worker (jeweils manchmal 100 MB) sofort in Apache hochgehen, und 500 Threads mit Anforderungen werden sofort an MySQL gesendet. Dies führt zu einem Anstieg der HTTP 50x-Fehler und einem möglichen Zusammenbruch.
Hier wird empfohlen, die Anzahl der Apache / PHP-Fpm-Worker auf die Anzahl zu beschränken, die in den Arbeitsspeicher passt, und in ähnlicher Weise die Anzahl der Threads in MySQL zu begrenzen, um einen Überlauf des verfügbaren Arbeitsspeichers zu verhindern. Die Idee ist einfach: Lassen Sie die Clients vor nginx warten, da dies bei asynchronen und nicht blockierenden TCP / IP-Sockets, die in Apache / MySQL sofort "brechen", etwas langsamer werden kann.
Von den ärgerlicheren Gründen könnte es Segfault PHP geben. In diesem Fall müssen Sie die Coredump-Erfassung aktivieren und gdb verwenden, um zu sehen, warum dies geschieht. In den meisten Fällen kann das Problem durch Aktualisieren / Konfigurieren von PHP umgangen werden.
Was bleibt hinter den Kulissen
Es gibt anhaltende Gerüchte, dass das moderne Frontend für das Web so aktiv begonnen hat, sein Leben zu leben, dass die in diesem Beitrag vorgestellten klassischen Lasttests des Backends nicht mehr alle möglichen Risiken des Einfrierens beim Erstellen einer Webseite in den Eingeweiden von Angular / React / Vue.js abdecken - daher
Verwenden Sie kein schweres und undurchsichtiges, schlecht getestetes Frontend. Falls erforderlich, können Sie die Lastketten an diese Situation anpassen.
Wenn die Ergebnisse der Stresstests im Backend gute Zahlen zeigten und die Website im Browser weiterhin langsamer wird, ist auf jeden Fall bereits klar, wer das dreiste rote Gesicht treffen soll :-)
Im Ernst, wir hoffen, in den nächsten Beiträgen dieses wichtige Thema behandeln zu können.
Zusammenfassung und Schlussfolgerungen
Insgesamt - die Organisation und Durchführung von Lasttests eines für die Entwicklung und das Geschäft nützlichen Websystems ist nicht kompliziert.
Ordnungsgemäß organisierte Lasttests sollten immer durchgeführt werden. Andernfalls besteht die Gefahr, dass während des Kampfeinsatzes größere Probleme auftreten, die nicht innerhalb weniger Tage behoben werden können.
Um Stresstests durchführen zu können, ist es wichtig, nicht nur Entwickler, sondern auch Experten für Betriebssysteme und Hardware-erfahrene Systemadministratoren zu gewinnen. Die Probleme, in einen Tausch zu geraten oder den lokalen Bereich von IP-Adressen zu überschreiten, verursachen keine Augenblutungen und Ohnmachtsanfälle.
Viel Glück Freunde und stellen Sie Fragen in den Kommentaren!