Dies ist eine maschinelle Übersetzung eines englischen Artikels, den ich zum Thema Pre-Launch Performance Testing – Technical Guide geschrieben habe. Wenn es einen eklatanten Übersetzungsfehler gibt, wenden Sie sich bitte an mich und ich werde ihn korrigieren. Herzlichen Dank.
Was ist zu testen?
In diesem Abschnitt werden die technischen Details der unten skizzierten Testszenarien erläutert.
- Testen Sie Ihre Anwendung drei Wochen lang im Sickerwasser.
- Starten Sie alle Komponenten ein paar Mal neu.
- Geben Sie eine halbe Million Datensätze in Ihre DB ein und führen Sie einen Regressionstest unter moderater Last durch.
(Im vorigen Abschnitt wurde ausführlich erläutert, warum Sie Ihre Software vor der Inbetriebnahme testen sollten und wie Sie den Beteiligten mitteilen sollten, dass Sie daran beteiligt sind).
Lassen Sie uns in der Mitte beginnen.
Alle Komponenten ein paar Mal neu starten
Dies ist eine einfache Sache. Die erste Runde können Sie manuell durchführen. Unabhängig vom Betriebssystem, der Plattform, ob sie virtualisiert, containerisiert, gedockt, karamellisiert oder pulverisiert ist, ob sie als systemd-Dienst läuft, ob es eine Automatisierung gibt, um sie neu zu starten, wenn sie ausfällt… Stoppen und starten Sie einfach jede Komponente der Reihe nach. Starten Sie alle Komponenten nacheinander neu.
Ich weiß, dass viele der infra/env/ops-Leute sagen werden, dass Docker sich darum kümmern wird, oder systemd, oder etwas anderes. Wie dem auch sei, als professioneller empirischer Skeptiker wollen Sie es einfach selbst sehen.
Wenn Sie es ein paar Mal manuell mit verschiedenen Stopp- und Startbefehlen gemacht haben, können Sie ein Skript schreiben und einen Ruhezustand zwischen dem Stopp und dem Start der Prozesse einfügen. Wählen Sie einen Bereich wie: 1 Sekunde, 10s, 30s 60, 120s, 600s 1200s und 2400s. Ja, ich weiß, dass Sie manche Prozesse über Nacht oder über das Wochenende laufen lassen müssen.
Führen Sie einige Runden von Blitzstarts durch, bei denen alle Komponenten ohne Verzögerung hintereinander gestartet werden, und machen Sie dann Stopps und Starts mit einer kurzen Verzögerung dazwischen, von 1 Sekunde bis 200 Sekunden, mit ähnlichen Abständen zwischen den Komponenten.
Spielen Sie mit der Reihenfolge, in der Sie sie neu starten. DB zuerst, DB zuletzt sind ein schönes Paar. Sie können auch mit dem Stoppen und Starten mehrerer Komponenten mit einer gewissen Überlappung spielen, z. B. Stoppen der Nachrichtenwarteschlange, Stoppen der DB, Stoppen der Datensammlungen, Starten der Nachrichtenwarteschlange, Starten der Datensammlung, Starten der BD. Sie verstehen, worauf ich hinaus will.
Durchsuchen Sie Ihre Protokolle nach Fehlern und Warnungen, und denken Sie daran, dass Sie davon ausgehen, dass Ihre Dienste immer in Betrieb sind und dass die Grundfunktionen funktionieren. Vergewissern Sie sich, dass alle Ihre Dienste nach den Neustarts wieder laufen, und überprüfen Sie die Funktionalität mit ein paar einfachen, leicht durchzuführenden Tests. Sie müssen keinen kompletten Smoke durchführen, sondern nur eine Handvoll leicht zu automatisierender Tests, die Lebenszeichen im System erkennen.
Eine Sache, die die Infrastrukturverantwortlichen auf die Palme bringen wird, ist der Neustart oder das Anhalten und Starten der DB(s). Normalerweise sagen sie: “Ach, das kann man doch nicht machen. Nun, man kann und man sollte. Das Leben kümmert sich nicht wirklich darum, was Sie mit Ihrer DB tun sollen. Das Leben wird Ihren DB nur an wirklich geschäftigen Tagen stoppen, wenn Ihr Kunde viel Geld verdient. Sie wollen also wissen, was an diesen Tagen tatsächlich passiert. Sagen Sie Ihren Leuten, dass das in Ordnung ist und dass Sie einfach nur neugierig sind und dass es noch kein Risiko darstellt, da wir noch nicht in Prod sind.
Wie man die Ergebnisse interpretiert
Vielleicht haben Sie wirklich Glück und alle Ihre Dienste kommen immer zurück und alles funktioniert und ist stabil. Ich habe diesen Test auf einer ganzen Reihe von Systemen durchgeführt und habe noch kein solches MVP gesehen, aber ich bin zuversichtlich. Eines Tages werde ich es sehen.
Wenn Sie nicht so viel Glück haben, erstellen Sie eine Liste der Szenarien, in denen die Fehler aufgetreten sind. Schreiben Sie sie in einen kleinen Bericht und fragen Sie die Leute nach Erklärungen, warum das passiert sein könnte. Sagen Sie nicht, dass dies gut oder schlecht ist, stellen Sie einfach die Tatsache fest und bitten Sie die Leute um Erklärungen. Dies sollte zu einer guten Unterhaltung über Ihre Ergebnisse führen, die die operativen Aspekte Ihres Produkts oder Ihrer Dienstleistung untermauern würde.
Lassen Sie uns zum nächsten Test übergehen.
- Testen Sie Ihre Anwendung drei Wochen lang auf Herz und Nieren.
Beginnen Sie sehr früh mit den Gesprächen mit den Beteiligten. Sechs Monate vor der geplanten Markteinführung sollten Sie mit den Beteiligten darüber sprechen, dass Sie eine produktionsähnliche Umgebung benötigen, in der Sie die Software von Anfang bis Ende testen können. Da dies mit Kosten verbunden ist, sollten Sie ein Portfolio zusammenstellen, in dem Sie begründen, warum dies notwendig ist, welche Vorteile sich daraus ergeben und welche Risiken bestehen, wenn Sie es nicht tun.
Bereiten Sie eine perfekte Kopie dessen vor, worauf Ihre Kunden Ihre Software laufen lassen sollen, oder, wenn Sie sie in der Cloud betreiben, die genaue Einrichtung, die Sie gegen Geld verkaufen wollen. In jedem Fall sollten Sie es überwachen lassen, nicht nur die Software-Statistiken, sondern auch die Hardware-Metriken. Eine langweilige Kombination aus Prometheus und Grafana ist für den Anfang gut. Beobachten Sie diese Diagramme wie ein Falke. (Oder messen Sie einfach Ihre Prozessmetriken mit Top jede Minute oder so und leiten Sie die Ergebnisse in eine Protokolldatei).
Warum drei Wochen?
Weil die meisten Ihrer Konkurrenten bestenfalls einen Tag oder ein Wochenende lang Tests durchgeführt haben. Daher sind die meisten ihrer Ressourcenlecks nie aufgetaucht. Die meisten ihrer betrieblichen Probleme traten nie auf, bevor sie in die Produktivphase gingen. Dann traten alle Kinderkrankheiten bei ihrem allerersten Kunden auf, was sie im besten Fall ein Vermögen und zu viele Zugeständnisse und im schlimmsten Fall ihren allerersten Kunden kostete.
Drei Wochen sind lang genug, um die meisten Ressourcenprobleme zu erkennen, sei es in Bezug auf Arbeitsspeicher, Festplatte oder RAM und die Anzahl der beim Start benötigten Kerne. Dennoch ist dies eine relativ kurze Zeitspanne, die im Projektplan eingeplant werden sollte, vor allem, wenn Sie einen Zeitraum von 6 Monaten veranschlagen.
Können Sie mit nur zwei Wochen auskommen? Sicher. Aber anstatt es bei zwei Wochen zu belassen, sollten Sie das Produkt auf den Markt bringen, aber auch das Experiment weiterlaufen lassen. Auf diese Weise haben Sie zwei Wochen Vorlaufzeit, falls etwas Unangenehmes passiert. (Kann ich mich mit drei Tagen begnügen? Sicher, wenn das alles ist, was Ihr Projektmanagement Ihnen bieten kann, nehmen Sie es, als hinge Ihr Leben davon ab. Denn das tut es. Aktualisieren Sie außerdem Ihren Lebenslauf, denn die sind nicht auf Dauer im Spiel.)
Warum der Verkehr?
Weil Ihre Kunden Ihre Software nicht einfach nur aus der Ferne betrachten werden. Sie werden Daten eingeben und erwarten, dass sie auch Ergebnisse sehen. Die meisten Ihrer Rennbedingungen treten nur dann auf, wenn Zeit und Verkehr vorhanden sind, um die unvorhergesehenen Pfade auszulösen.
Wenn Sie können, legen Sie dies zusätzlich zu der halben Million Datensätze in die DB. Das wäre auf jeden Fall ein echter Stabilitäts- und Robustheitstest, und zwar aus allen Blickwinkeln.
Was ist, wenn Sie den Verkehr nicht synthetisieren können? Man kann auch ohne automatisierten Datenverkehr auskommen, aber das Experiment ist dann sehr viel eingeschränkter in Bezug auf das, was man herausfinden kann. Wenn es zu schwierig ist, Traffic zu generieren, können Sie darauf verzichten, aber dann sollten Sie zumindest alle regulären Tests auf diesem System durchführen und eine oder zwei Mobtest-Sitzungen organisieren, bei denen alle Leute mit mindestens einem funktionierenden Finger das Produkt für Sie testen.
Welche Art von Traffic sollten wir darauf laufen lassen?
Sie wollen die Art von Verkehr sehen, von der Sie glauben, dass Ihre ersten Kunden sie nutzen werden. Es sollte gelegentlich falsche Eingaben geben, einige Fehler, fehlende Felder, Werte außerhalb des zulässigen Bereichs, Parameter der falschen Art. Es geht darum, dass über einen längeren Zeitraum einige Daten durch das System fließen.
Jeder Datenverkehr ist besser als keiner. Wenn Ihre Anwendung zustandslos ist und Sie einen B2C-Dienst für die Öffentlichkeit anbieten möchten, holen Sie Ihren JMeter heraus und erstellen Sie täglich einige Glockenkurven. Führen Sie dann eine einfache Buckelkurve (der Verkehr hat einen Höhepunkt um 10 oder 15 Uhr), eine doppelte Buckelkurve (8-9 Uhr und 18-7 Uhr) und eine dreifache Buckelkurve (8-9 Uhr, 12-1 und 18-7 Uhr) durch, mit einem oder zwei gelegentlichen Spitzen (Merkating hat eine E-Mail-Kampagne verschickt).
Wenn es sich bei Ihrem Produkt um ein zustandsbehaftetes Produkt handelt, sollten Sie Ihre DB-lastigsten Operationen aufzeichnen. Legen Sie diese dann in eine ewige while-Schleife auf einer separaten Maschine, als Low-End-Lösung. Wenn Sie etwas wirklich Ausgefeiltes wollen, besorgen Sie sich eine Runner-VM und verwenden Sie JMeter CLI als Generator, um Ihren gemischten Datenverkehr mit 1-30 % fehlerhaftem Datenverkehr in eine hübsche Glockenkurve zu bringen.
Wie viel Datenverkehr sollten wir darauf laufen lassen?
Denken Sie daran, dass es sich in diesem Stadium nicht um einen Stresstest handelt, Sie müssen also nicht Millionen von Transaktionen durchführen. Imitieren Sie einfach drei Wochen lang an einem verkehrsreichen Tag ohne Unterbrechung einen normalen Mann mit normalem Verkehr. Sie können versuchen, Ihren Sättigungsgrad für das gegebene Muster herauszufinden und 50-80 % dieser Menge laufen lassen. Wenn Sie nicht die Kapazität haben, damit herumzuspielen, fragen Sie Ihren Manager, mit wie viel Verkehr Sie maximal rechnen sollten. Da deren Schätzungen in der Regel um das 20-fache unter den tatsächlichen Werten liegen, sollten Sie deren Schätzung als Spitzenwert für Ihre Glockenkurven verwenden.
Wie sind die Ergebnisse zu interpretieren?
Wenn Sie eine gute Überwachung eingerichtet haben, sollten Sie die Diagramme täglich überprüfen. Jeder Tiefpunkt oder unerklärliche Spitzenwert sollte untersucht werden. Ein seltsamer Verdacht ist, dass die DB-Antwortzeit um 2:30 Uhr morgens wirklich schlecht ist. Ihre DB führt Wartungsskripte aus, also ist das kein Problem. Es sei denn, es ist 2:30 Uhr GMT, was 7:30 Uhr PST entspricht. In diesem Fall sollten Sie die automatischen Bereinigungsskripte nachbessern. Wenn Sie das nicht tun, sollten Sie die Protokolle durchforsten, nach Fehlern suchen und einfach die Protokolle beobachten, um zu sehen, ob etwas Ungewöhnliches passiert.
Sie gehen davon aus, dass die gesamte Lösung ohne Unterbrechung und ohne Hilfe weiterläuft. Wenn Sie eingreifen müssen (Protokollrotation, Prozessneustart, Docker-Space, DB-Verbindungspool, Hund hat Netzwerkkabel zerkaut), stellen Sie sicher, dass diese Aufgaben automatisiert und in Cron geplant sind.
Als Faustregel gilt: Jedes Mal, wenn Ihre Software abstürzt, wird Ihr Timer neu gestartet. Beheben Sie alle Fehler, bis Ihre Software bei mäßiger Belastung drei Wochen lang laufen kann. Wenn die Leute darüber unglücklich sind, ist ein Argument, das schwer zu diskutieren ist, dass jeder Fehler, den Sie finden, vier- bis fünfmal teurer ist, um ihn in der Produktion zu beheben. Wenn Sie also nur 2 Tage für die Untersuchung und die Behebung des Fehlers aufwenden und mit einem Ingenieur-Tagessatz von 2.000 $/£/Euro kalkulieren, haben Sie ihnen gerade acht Riesen gespart. Wir können also sicherlich noch ein wenig warten, um sicherzustellen, dass wir unser Jahresbudget im nächsten Jahr nicht für die Wartung ausgeben.
Schließlich die Datenbank
Legen Sie eine halbe Million Datensätze in Ihre DB ein und führen Sie einen Regressionstest unter mäßiger Last durch
Wie viel Datenverkehr sollten wir darauf laufen lassen?
Wenn Sie an diesem Punkt angelangt sind, haben Sie bereits eine ziemlich gute Infrastruktur aufgebaut. Wenn Sie es richtig anstellen, können Sie die letzten 21 Tage nutzen, um die 500.000 Abonnements, Produktartikel, zufällige Sensorwerte oder gefälschte Zimmerbuchungen in Ihre DB zu bekommen. Jeden Tag 25.000 neue Datenelemente. Das sind etwa 1.000 pro Stunde, also etwa alle drei Sekunden ein neues Element. Das sollte in jedem Produktionssystem ohne Probleme machbar sein.
Wichtig ist, dass Sie reichhaltige, zufällige Daten in Ihrer Datenbank haben, nicht eine sequentielle UUID von 1 bis 525001 mit “asd” als Vorname und “qwerty” als Nachname. Diese Profile sollten richtige Zufallsnamen, Adressen, Postleitzahlen auf verschiedenen Kontinenten, Kaufhistorien und sogar zurückgegebene Artikel enthalten. Die meisten Tools generieren gerne Zufallsdaten jeglicher Art, machen Sie also von dieser Möglichkeit Gebrauch. Löschen Sie außerdem einige der von Ihnen erstellten Daten. Wir sprechen hier von der zufälligen Löschung von einigen Prozent Ihrer Daten, so dass auch in sortierten oder geordneten Listenansichten, die erstellt werden, Lücken entstehen.
Welche Art von Datenverkehr sollten wir darauf laufen lassen?
Starten Sie einen abwechslungsreichen Datenverkehr auf Ihrer Instanz, führen Sie Ihre üblichen CRUD-Datensätze auf automatisierte Weise aus und gehen Sie manuell durch die gesamte Regressionssuite, die Sie haben. Nehmen Sie sich die Zeit, die Sie brauchen, denn es kann sein, dass Sie dieselben Tests mit ein paar Variationen wiederholen wollen.
Wenn Sie in einem Browser arbeiten, lassen Sie ein Browser-Terminal geöffnet. Zeichnen Sie auch den Netzwerkverkehr auf. Wenn Sie von einer Shell aus arbeiten, lassen Sie eine separate Shell in GNU screen geöffnet und verfolgen Sie die Protokolle während des Tests weiter.
Einige der Dinge, die Sie finden, werden nicht reproduzierbar sein, oder zumindest nicht leicht, also gibt es zwei Dinge, die Sie tun können, um dies zu verhindern: Erstens, stellen Sie sicher, dass die Protokollierung auf Debug-Level eingestellt ist, zweitens, kaufen Sie eine professionelle Version von Snagit, und zeichnen Sie Ihre Sitzungen auf, von dem Moment an, in dem Sie die Regressionstests einrichten. Zeichnen Sie alles auf, und zwar schon bei der Einrichtung. Sagen Sie sich nicht einfach: “Ich richte das ein und fange mit der Aufzeichnung an, wenn ich mit den eigentlichen Tests beginne. Nein, nein. Beginnen Sie mit der Aufzeichnung und dann können Sie mit der Einrichtung beginnen. Sie können mir später dafür danken.
Wie man die Ergebnisse interpretiert
Wenn Sie können, sollten Sie ein Tool zur Überwachung der Datenbank einsetzen. Wenn nicht, müssen Sie die Protokolle auswerten.
Sie halten Ausschau nach langsamen Antworten, ungewöhnlichen Verzögerungen und allem, was sich anders anfühlt als bei früheren Tests. Viele Dinge können sich einfach anders anfühlen, daher sollten Sie alle Beteiligten fragen, ob sie dies für in Ordnung halten – und Sie schicken ihnen die Protokolle, die Zeitstempel und die Videoaufzeichnungen mit.
Wenn sich irgendetwas langsamer anfühlt als vorher oder einfach nur allgemein langsam ist, versuchen Sie, es ein paar Mal zu reproduzieren. Ist es immer langsam? Messen Sie die Zeit, wie langsam es ist, und kleben Sie einen großen Timer auf den aufgezeichneten Bildschirm, so dass er ins Auge fällt. Besprechen Sie die Ergebnisse mit Ihren Produktverantwortlichen, ob es sich um eine Regression handelt oder nicht, und besprechen Sie mit Ihrem Entwicklungsteam, ob es etwas gibt, das sie in den Abgründen der Datenbank suchen müssen.
Überwachen Sie die Protokolle auf Fehler, denn langsame Antworten zeigen sich vielleicht nicht auf der Benutzeroberfläche, können aber im Hintergrund Probleme verursachen. Kommt es bei Ihren Aufrufen zu Zeitüberschreitungen? Ist das akzeptabel? Einfache Zeitüberschreitungen können bei entsprechendem Druck zu kaskadenartigen Ausfällen führen, also setzen Sie das System ruhig stärker unter Druck, wenn Sie etwas Unerwartetes feststellen. Erhöhen Sie den automatischen Datenverkehr auf die doppelte Last und führen Sie den Test erneut durch.
Hier sind wir nun, viertausend Wörter später, bereit, einen Blick auf das zweite Szenario zu werfen, wenn Sie bereits einige Kunden haben und wissen, dass Sie die Leistung der Software testen müssen.
