Lasttests

Welche Faktoren beeinflussen die Testergebnisse?

• Die Netzwerkverzögerung vom Lasttest-Tool zum Server (empfohlen wird, im Intranet oder lokal zu testen)
• Die Bandbreite vom Lasttest-Tool zum Server (empfohlen wird, im Intranet oder lokal zu testen)
• Ob HTTP Keep-Alive aktiviert ist (empfohlen, es zu aktivieren)
• Ob die Anzahl der gleichzeitigen Verbindungen ausreichend ist (bei externen Tests sollte eine höhere Zahl an gleichzeitigen Verbindungen aktiv sein)
• Ob die Anzahl der Serverprozesse angemessen ist (bei einem helloworld Beispiel wird empfohlen, die Anzahl der Prozesse mit der Anzahl der CPU-Kerne gleichzusetzen, bei Datenbankprozessen wird eine vierfache Anzahl empfohlen)
• Die Performance der Anwendung selbst (z. B. ob eine externe Datenbank verwendet wird)

Was ist HTTP Keep-Alive?

Der HTTP Keep-Alive-Mechanismus ist eine Technik, die es ermöglicht, mehrere HTTP-Anfragen und -Antworten über eine einzelne TCP-Verbindung zu senden. Dies hat einen großen Einfluss auf die Ergebnisse von Leistungstests; bei deaktiviertem Keep-Alive könnte der QPS stark fallen.
Heutzutage sind die meisten Browser so konfiguriert, dass Keep-Alive standardmäßig aktiviert ist. Das bedeutet, dass der Browser nach dem Zugriff auf eine HTTP-Adresse die Verbindung vorübergehend offen hält und beim nächsten Request diese Verbindung wiederverwendet, um die Leistung zu verbessern.
Es wird empfohlen, Keep-Alive während der Lasttests zu aktivieren.
Wenn Keep-Alive deaktiviert ist, können die lokalen Client-Ports schnell im state timewait verbraucht werden, was sich darin äußert, dass die Gesamtanzahl der Anfragen ab einem bestimmten Punkt (normalerweise etwa 28.000) fehlschlägt.

Wie aktiviert man HTTP Keep-Alive während Lasttests?

Wenn Sie das ab-Programm für Lasttests verwenden, sollten Sie den Parameter -k hinzufügen, zum Beispiel ab -n100000 -c200 -k http://127.0.0.1:8787/.
Bei apipost müssen Gzip-Header in den Rückgabekopf eingefügt werden, um Keep-Alive zu aktivieren (ein Fehler in apipost, siehe unten).
Andere Lasttest-Programme haben in der Regel Keep-Alive standardmäßig aktiviert.

Warum ist die QPS bei externen Lasttests sehr niedrig?

Eine hohe Verzögerung im Internet führt zu einer niedrigen QPS, was normal ist. Beispielsweise könnte die QPS beim Testen von baidu nur einige Dutzend betragen.
Es wird empfohlen, interne oder lokale Tests durchzuführen, um die Auswirkungen der Netzwerkverzögerung auszuschließen.
Wenn es unbedingt erforderlich ist, externe Tests durchzuführen, kann die Erhöhung der Anzahl gleichzeitiger Verbindungen die Durchsatzrate erhöhen (vorausgesetzt, die Bandbreite ist ausreichend).

Warum sinkt die Leistung nach der Proxy-Nutzung mit nginx?

nginx benötigt Systemressourcen zur Ausführung. Zudem verbraucht die Kommunikation zwischen nginx und webman ebenfalls einige Ressourcen.
Die Systeme Ressourcen sind jedoch begrenzt und webman kann nicht auf alle verfügbaren Systemressourcen zugreifen, weshalb es normal ist, dass die Gesamtleistung des Systems sinkt.
Um die Leistungseinbußen durch den nginx-Proxy so gering wie möglich zu halten, kann es sinnvoll sein, die nginx-Protokollierung zu deaktivieren (access_log off;), und Keep-Alive zwischen nginx und webman zu aktivieren. Weitere Informationen finden Sie unter nginx代理.

Darüber hinaus verbraucht HTTPS mehr Ressourcen im Vergleich zu HTTP, da HTTPS ein SSL/TLS-Handshake durchführt, Daten verschlüsselt und entschlüsselt, und die Paketgrößen größer sind, was zu höherem Bandbreitenverbrauch führt. All dies kann die Leistung beeinträchtigen.
Wenn bei den Tests kurze Verbindungen verwendet werden (d. h. Keep-Alive ist nicht aktiviert), erfordert jeder Request zusätzliche SSL/TLS-Handshake-Kommunikation, was die Leistung erheblich verringert. Es wird empfohlen, bei HTTPS-Tests Keep-Alive zu aktivieren.

Wie kann man erkennen, ob das System die Leistungsgrenze erreicht hat?

Im Allgemeinen zeigt eine CPU-Auslastung von 100 % an, dass die Systemleistung das Maximum erreicht hat. Wenn die CPU noch frei ist, ist der maximale Punkt noch nicht erreicht. In diesem Fall können Sie die Anzahl der gleichzeitigen Verbindungen erhöhen, um die QPS zu steigern.
Wenn die Erhöhung der gleichzeitigen Verbindungen die QPS nicht steigert, könnte das daran liegen, dass nicht genügend webman-Prozesse vorhanden sind; in diesem Fall sollten Sie die Anzahl der webman-Prozesse erhöhen. Wenn das immer noch nicht ausreicht, sollten Sie die Bandbreite überprüfen.

Warum ist die Leistung von webman niedriger als die des Gin-Frameworks von Go in meinen Tests?

Die Tests von techempower zeigen, dass webman in allen Kategorien wie einfache Textverarbeitung, Datenbankabfragen und Datenbankaktualisierungen deutlich besser abschneidet als Gin, oft mit nahezu doppelter Leistung.
Wenn Ihre Ergebnisse anders sind, könnte das daran liegen, dass Sie in webman ORM verwenden, was zu erheblichen Performanceeinbußen führen kann. Vergleichen Sie daher die Leistung von webman + nativen PDO und Gin + nativen SQL.

Wie viel Leistung geht beim Einsatz von ORM in webman verloren?

Hier sind einige Testergebnisse:

Umgebung
Server: Alibaba Cloud 4 Kerne, 4 GB RAM, lokale MySQL-Datenbank, Auswahl einer zufälligen Datenzeile aus 100.000 Einträgen mit JSON-Rückgabe, Test auf dem lokalen Rechner.

Bei Verwendung von nativen PDO
webman QPS beträgt 17.800

Bei Verwendung von Laravel Db::table()
webman QPS sinkt auf 9.400 QPS

Bei Verwendung des Laravel Models
webman QPS sinkt auf 7.200 QPS

Die Ergebnisse von thinkORM sind ähnlich, ohne große Unterschiede.

Hinweis
Obwohl die Verwendung von ORM die Leistung vermindern kann, ist die Leistung für 99 % der Anwendungsfälle bereits mehr als ausreichend. Wenn Sie zu den verbleibenden 1 % gehören, kann dies einfach durch mehr CPU oder Serverressourcen gelöst werden.
Wir sollten einen Gleichgewichtspunkt zwischen Entwicklungsproduktivität, Wartbarkeit und Leistung finden, anstatt nur die Leistung zu maximieren.

Warum ist die QPS bei Lasttests mit apipost sehr niedrig?

Der Lasttest-Modul von apipost hat einen Fehler. Wenn der Server die Gzip-Header nicht zurückgibt, kann Keep-Alive nicht aufrechterhalten werden, was zu einem massiven Leistungseinbruch führt.
Als Lösung fügen Sie beim Zurückgeben die Datenkompression und Gzip-Header hinzu, zum Beispiel:

<?php
namespace app\controller;
class IndexController
{
    public function index()
    {
        return response(gzencode('hello webman'))->withHeader('Content-Encoding', 'gzip');
    }
}

Darüber hinaus ist apipost in einigen Fällen möglicherweise nicht in der Lage, zufriedenstellende Lasttests durchzuführen. Dies zeigt sich darin, dass unter derselben Last apipost etwa 50 % weniger QPS als ab erreicht.
Es wird empfohlen, tools wie ab, wrk oder andere professionelle Lasttest-Software zu verwenden, anstelle von apipost.

Angemessene Anzahl von Prozessen einrichten

webman hat standardmäßig die Anzahl der Prozesse auf CPU*4 eingestellt. Tatsächlich erreichen Lasttests ohne Netzwerk-I/O (z. B. das helloworld-Beispiel) mit einer Anzahl von Prozessen, die der Anzahl der CPU-Kerne entspricht, die optimale Leistung, da dadurch die Prozesswechselkosten verringert werden.
Wenn jedoch blockierende I/O-Aktivitäten wie Datenbanken oder Redis beteiligt sind, kann die Anzahl der Prozesse auf das 3- bis 8-fache der CPU-Kerne erhöht werden, da hier benötigt wird, um die Parallelität zu erhöhen, und die Prozesswechselkosten im Vergleich zu blockierenden I/O-Aktivitäten praktisch vernachlässigbar sind.

Einige Referenzbereiche für Lasttests

Cloud-Server 4 Kerne, 4 GB RAM, 16 Prozesse, lokale/intranet Tests

Daten von externen techempower Lasttests

Beispiel für Lasttest-Befehle

ab

# 100000 Anfragen, 200 gleichzeitige Verbindungen, Keep-Alive aktiviert
ab -n100000 -c200 -k http://127.0.0.1:8787/

# 100000 Anfragen, 200 gleichzeitige Verbindungen, Keep-Alive deaktiviert
ab -n100000 -c200 http://127.0.0.1:8787/

wrk

# 200 gleichzeitige Verbindungen, 10 Sekunden Test, Keep-Alive aktiviert (Standard)
wrk -c 200 -d 10s http://example.com