[PYTHON] Kenntnisse über Mindestauslastungstests, die beim ersten Auslastungstest des API-Servers erworben wurden

Übrigens ist die Serverkonfiguration zum Zeitpunkt des Auslastungstests so.

Um die Anzahl pro Einheit zu ermitteln, haben wir zunächst einen Auslastungstest mit einem API-Server durchgeführt. New Relic wird nur auf API Server Nr. 1 installiert.

Erstellen von Lasttestszenarien mit Locust

Nun bereiten wir Locust auf die nächste Ladung vor. Hier ist eine Referenz zur Verwendung von Locust. Erstellen Sie ein Szenario, indem Sie davon ausgehen, welche API mit welcher Geschwindigkeit aufgerufen wird.

Das folgende Beispiel zeigt ein einfaches Szenario: Die Benutzerregistrierung wird beim Erstellen eines Clients nur einmal durchgeführt, und die Anmelde-API und die Status-API werden danach in keiner bestimmten Reihenfolge aufgerufen. Der Taskdekorator gibt jedoch den Prozentsatz an, zu dem jede API aufgerufen wird.

# -*- coding:utf-8 -*-
"""
Ein Szenario einer Woche allgemeiner Bewegung

"""
from locust import HttpLocust, task, TaskSet


class ScenarioTaskSet(TaskSet):

    def on_start(self):
        """
Benutzer Registration
Bereiten Sie hier die notwendigen Informationen für jeden Kunden vor
        """
        self.user_id = "xxxxxxxxxxxxxx"
        self.client.headers = {
            'Content-Type': 'application/json; charset=utf-8',
        }
        self.client.post(
            '/user/signup',
            json={
                "user_id": self.user_id,
            }
        )    
    
    @task(1)
    def signin(self):
        """
Benutzer-Anmeldung
        """
        self.client.post(
            '/user/signin',
            json={
                "client_id": self.client_id,
            }
        )

    @task(10)
    def status(self):
        """
Benutzerinformationen abrufen
        """
        self.client.post(
            '/client/status',
            json={
                "client_id": self.client_id,
            }
        )        
        

class MyLocust(HttpLocust):
    task_set = ScenarioTaskSet
    #Minimale Wartezeit für die Ausführung der Aufgabe
    min_wait = 1000
    #Maximale Wartezeit für die Ausführung der Aufgabe
    max_wait = 1000

Führen Sie es dann mit dem folgenden Befehl aus.

locust -H http://apiserver.co.jp(← Server, den Sie laden möchten)

Wenn Sie mit einem Browser darauf zugreifen und der TOP-Bildschirm der Heuschrecke angezeigt wird, ist die Vorbereitung der Heuschrecke abgeschlossen. Danach können Sie den Belastungstest starten, indem Sie die Anzahl der Benutzer und den Verstärkungsfaktor angeben.

Wenn Sie tatsächlich starten, können Sie die Informationen sehen, die wie folgt in den Browser geladen werden.

locust hat eine Funktion zum Synchronisieren mit mehreren Slaves. Dieses Mal haben wir ungefähr 10 Server für locust vorbereitet und schließlich den API-Server von 10 locust-Servern geladen.

New Relic

Wenn die Heuschrecke fertig ist, versuchen Sie, die Last aufzubringen, und überprüfen Sie den Ladestatus mit New Relic. Bei diesem Lasttest spielt dieses neue Relikt eine führende Rolle. Wenn Sie die Leistung optimieren, laden Sie es mit Heuschrecke, überprüfen Sie den Teil, an dem die Last mit New Relic aufgebracht wird, und reparieren Sie es mit einem Stimmstern. Mach die Arbeit. (Informationen zum Einrichten von New Relic in der Django-App sind hilfreich.](Https://gist.github.com/voluntas/7278351))

Überprüfen Sie New Relic

Laden wir es tatsächlich und werfen einen Blick auf New Relic. Unten ist die "Übersicht" von New Relic. Sie können die gesamten Informationen auf dieser Seite sehen. Dies sind die Daten vor dem Einstellen, aber der Durchsatz beträgt 43 U / min. Das ist ziemlich schrecklich. Im Diagramm "Antwortzeit für Web-Tarnsaction" ist es für jede Art der Verarbeitung farbcodiert. In diesem Beispiel nimmt Hellblau den größten Teil davon ein, sodass Sie sehen können, dass die Python-Verarbeitung insgesamt zu lange dauert. Ich werde. Wenn Sie sich den Übergang unten ansehen, können Sie auch feststellen, dass die API-Verarbeitung zu lange dauert und dass bei der Fehlerrate viele Fehler auftreten.

Wir werden basierend auf diesen Daten abstimmen und sie auf die Zielleistung erhöhen. Lassen Sie mich nun ein einfaches Beispiel für die Abstimmung geben.

Tuning

Sehen Sie sich die Transaktionsseite von New Relic an, um festzustellen, welche APIs der Engpass bei langsamer Verarbeitung sind. Wenn Sie Most time conuming auswählen, werden die Anforderungen in der Reihenfolge der langsamsten Verarbeitung angezeigt.

Übrigens sind diesmal die meisten Ursachen die Python-Verarbeitung, daher ist "App Server-Ausfall" ganz blau, aber normalerweise wird das Verhältnis für jede Verarbeitung so dargestellt.

Darüber hinaus wird unter dem Diagramm eine "Aufschlüsselungstabelle" angezeigt, in der Sie sehen können, wo es Zeit braucht, einschließlich SQL. Wenn die Anzahl der SQL-Abfrageaufrufe (durchschnittliche Aufrufe) ungewöhnlich hoch ist oder die Verarbeitung lange dauert, beheben Sie sie. Dieses Mal habe ich Abfragen, die mehrfach aufgerufen wurden, zu einer kombiniert und Avg-Aufrufe auf 1 gesetzt, und für SQL mit langsamer Zeit den INDEX angepasst und die Zeit verkürzt.

Die Details der Funktion, die auf den Teil verweist, den Python verarbeitet, können hier jedoch nicht bestätigt werden. Sie können dann zur Seite "Transaktionsablaufverfolgung" unter "Transaktionsablaufverfolgung" unter "Aufschlüsselungstabelle" gehen, um detailliertere Informationen anzuzeigen.

Beispielsweise wird unter "Trace-Details" der Verarbeitungsinhalt auf diese Weise in der Reihenfolge der Verarbeitung angezeigt. Daher ist es sehr praktisch, wenn Sie den reparierten Teil markieren möchten, welcher Teil der Verarbeitung die Ursache ist.

In diesem Fall wurden vor INSERT die aus den beiden Tabellen ausgewählten Inhalte durch Python-Loop-Verarbeitung zusammengefasst und die Inhalte INSERTed.

Durch Vergleich mit "Trace-Details" können Sie beurteilen, dass der geladene Anwendungscode Teil der Schleifenverarbeitung von Python ist. Durch die Reduzierung der Last der Schleifenverarbeitung konnten wir daher den problematischen Teil des Anwendungscodes beseitigen.

Grundsätzlich kann durch Wiederholen von "Laden → Untersuchen der Ursache → Beheben der Ursache und Verbessern der Leistung" die Anforderung stabil bis zum Zielwert der CPU-Auslastung verarbeitet werden, und es gibt keinen Platz mehr, um sie zu reparieren. Wir werden die Leistung des Servers verbessern, indem wir alle Ursachen einschließlich der SQL-Verarbeitung und der Code-Verarbeitung verbessern.

Grenzwert messen

Nach dem Einstellen des Servers ist es Zeit, die Grenzwerte zu messen. Da die Obergrenze bei 50% CPU-Auslastung liegt, wird die Last angewendet, während die CPU-Auslastung des Servers mit dem Befehl top überprüft wird.

Überprüfen Sie zunächst, bis die CPU-Auslastung 50% erreicht, dass die Verarbeitung auf dem Bildschirm des Ortsbrowsers stabil ist, passen Sie den Ort an und halten Sie die Last eingeschaltet, wenn die CPU-Auslastung bei etwa 50% liegt. .. Zu diesem Zeitpunkt können Sie die Drehzahl aus dem RPS von Locust berechnen. Dieses Mal passen wir die Leistung in Bezug auf den numerischen Wert von New Relic an. Überprüfen Sie daher die Drehzahl von New Relic, um sie zu vereinheitlichen, und das Limit des Servers Es wurde als Wert festgelegt.

Infolgedessen wurde die Leistung eines Servers festgelegt. Wenn Sie also die Anzahl erhöhen und prüfen können, ob die Last ordnungsgemäß verteilt ist, können Sie einfach die erforderliche Anzahl für den Betrieb vorbereiten.

Dies ist ein schwieriger Belastungstest

Ich habe kurz die Methode des Belastungstests vorgestellt, aber dies ist nur ein Beispiel, und wenn Sie den Test tatsächlich versuchen, stehen verschiedene Wände auf.

• Es ist schwierig, an Locust-Szenarien zu denken ――Es war schwierig, das Szenario anzupassen, wenn eine Abhängigkeit zwischen Aufgaben besteht, und die Aktualisierungshäufigkeit von Daten zu berücksichtigen. Insbesondere hängt die Häufigkeit der Datenaktualisierungen direkt mit der Last zusammen, sodass dies allein die Ergebnisse des Lasttests erheblich verändert. --Striken der API eines externen Dienstes ――In diesem Fall musste berechnet werden, wie stark sich die Auslastung des externen Dienstes auswirken würde, und es war schwierig, sich eine Methode vorzustellen.
• Es ist schwierig, die Ursache der Belastung zu untersuchen ――Wenn der Code stark ausgelastet zu sein scheint oder wenn er durch eine SQL-Anweisung verursacht wird, können Sie ihn beheben, indem Sie ihm einen Stern hinzufügen, indem Sie die hier vorgestellte Prozedur befolgen. Es gibt viele Muster, bei denen es auf den ersten Blick kein Problem zu geben scheint, aber es funktioniert aus irgendeinem Grund nicht. In diesem Fall ist viel Wissen und Erfahrung erforderlich, um über den Lösungsansatz aus verschiedenen Blickwinkeln nachzudenken.

Zusammenfassung

Wenn Sie die diesmal eingeführte Verwendung und Optimierung von New Relic unterdrücken, können Sie möglicherweise einen grundlegenden Lasttest durchführen. In der Realität treten jedoch mehr Probleme auf und es sind unterschiedliche Abstimmungsansätze erforderlich. Wenn Sie zum ersten Mal hier sind, empfehlen wir Ihnen, den Test mit dem Rat einer erfahrenen Person durchzuführen. Wenn Sie der Meinung sind, dass Sie die Leistung ganz gut verbessert haben, wenn Sie eine erfahrene Person bitten, dies zu überprüfen, reicht die Last tatsächlich nicht aus </ b>.