TOC

Benchmarking der HTTP-Latenz mit wrk unter Ubuntu 14.04

Einführung

Dieser Artikel befasst sich mit einem Open-Source-HTTP-Benchmarking-Tool namens wrk, das die * Latenz * Ihrer * HTTP * -Dienste bei * hoher * Auslastung misst.

Latency bezieht sich auf das Zeitintervall zwischen dem Zeitpunkt der Anforderung (von wrk) und dem Zeitpunkt des Empfangs der Antwort (vom Service). Dies kann verwendet werden, um die Wartezeit zu simulieren, die ein Besucher auf Ihrer Website erleben würde, wenn er sie mit einem Browser oder einer anderen Methode besucht, die HTTP-Anforderungen sendet.

wrk eignet sich zum Testen von Websites oder Anwendungen, die auf HTTP basieren, z. B .:

  • Rails und andere Ruby-Anwendungen

  • Express und andere JavaScript-Anwendungen

  • PHP-Anwendungen

  • Statische Websites, die auf Webservern ausgeführt werden

  • Websites und Anwendungen hinter Load Balancern wie Nginx

  • Deine Caching-Ebene

Tests * können * nicht mit * echten * Benutzern * verglichen werden, aber sie sollten Ihnen eine gute * Schätzung * der erwarteten Latenz geben, damit Sie Ihre Infrastruktur besser planen können. Tests können Ihnen auch Einblick in Ihre Leistungsengpässe geben.

wrk ist Open Source und kann unter GitHub gefunden werden.

Es ist sehr stabil und ermöglicht dank seines Multithread-Charakters die Simulation hoher Lasten. Das größte Merkmal von wrk ist die Fähigkeit, Lua -Skripte zu integrieren, die viele Möglichkeiten bietet, wie z.

Voraussetzungen

Die Infrastruktur, die wir in diesem Tutorial verwenden werden, ist in der folgenden Abbildung dargestellt:

image: https://assets.digitalocean.com/articles/wrk-ubuntu14.04/wrk-application-overview.png [Infrastrukturübersicht]

Wie Sie sehen, verwenden wir wrk in einem sehr einfachen Szenario. Wir werden eine Express -Anwendung auf Node.js vergleichen.

Wir werden * zwei Tröpfchen * drehen: eines für wrk, das die Last erzeugt, und das andere für die Anwendung. Wenn sie sich in derselben Box befänden, würden sie um Ressourcen konkurrieren und unsere Ergebnisse wären nicht zuverlässig.

Die Maschine, deren Maßstäbe stark genug sein sollten, um das belastete System zu handhaben, aber in unserem Fall ist die Anwendung so einfach, dass wir Maschinen der gleichen Größe verwenden werden.

  • Drehen Sie zwei Droplets in derselben Region, da diese über eine private IP kommunizieren

  • Rufen Sie ein Droplet * wrk1 * und das andere * app1 * auf, um diesem Tutorial zu folgen

  • Wählen Sie * 2 GB * Speicher

  • Wählen Sie * Ubuntu 14.04 *

  • Wählen Sie im Bereich "Verfügbare Einstellungen" die Option "Privates Netzwerk" aus

  • Erstellen Sie auf jedem Server einen sudo user

Kleinere Tröpfchen funktionieren auch, aber Sie sollten bei den Testergebnissen mit einer höheren Latenz rechnen. In einer realen Testumgebung sollte Ihr App-Server dieselbe Größe haben, die Sie in der Produktion verwenden möchten.

image: https://assets.digitalocean.com/articles/wrk-ubuntu14.04/do-setup-infrastructure-with-notes.png [Digital Ocean Infrastructure Setup Preview]

Wenn Sie Hilfe beim Einrichten von Droplets benötigen, lesen Sie bitte this article.

Schritt 1 - Beide Server: Installieren Sie Docker

Um uns das Leben zu erleichtern, verwenden wir Docker, damit wir wrk und unsere Anwendung in Containern starten können. Damit können wir das Einrichten von Node.js-Umgebungen, npm-Modulen und deb-Paketen überspringen. Alles, was wir brauchen, ist das Herunterladen und Ausführen des entsprechenden Containers. Die eingesparte Zeit wird in das Lernen von Wrk investiert.

Wenn Sie mit Docker nicht vertraut sind, können Sie hier eine Einführung zu Docker lesen: here.

  • Hinweis: * Die Befehle in diesem Abschnitt sollten auf * beiden Droplets * ausgeführt werden.

Melden Sie sich zum Installieren von Docker bei Ihren Servern an und führen Sie die folgenden Befehle aus. Aktualisieren Sie zunächst die Paketlisten:

sudo apt-get update

Installieren Sie Wget und cURL:

sudo apt-get install -y wget curl

Laden Sie Docker herunter und installieren Sie es:

sudo wget -qO- https://get.docker.com/ | sh

Fügen Sie Ihren Benutzer zur Gruppe "+ docker +" hinzu, damit Sie Docker-Befehle ohne sudo ausführen können:

sudo gpasswd -a ${USER} docker
sudo service docker restart
newgrp docker

Um zu überprüfen, ob + docker + korrekt installiert ist, verwenden Sie diesen Befehl:

docker --version

Sie sollten die folgende oder eine ähnliche Ausgabe erhalten:

OutputDocker version 1.7.1, build 786b29d

Schritt 2 - Testanwendung vorbereiten

Führen Sie diese Befehle im Droplet * app1 * aus.

Zu Testzwecken veröffentlichte der Autor ein Docker image in der öffentlichen Docker-Registrierung. Es enthält eine in Node.js geschriebene HTTP-Debugging-Anwendung. Es ist kein Leistungstier (wir werden heute keine Rekorde brechen), aber es ist genug zum Testen und Debuggen. Sie können den Quellcode here auschecken.

In einem realen Szenario möchten Sie natürlich Ihre eigene Anwendung testen.

Bevor wir die Anwendung starten, speichern wir die private IP-Adresse des Droplets in einer Variablen mit dem Namen "+ APP1_PRIVATE_IP +":

export APP1_PRIVATE_IP=$(sudo ifconfig eth1 | egrep -o "inet addr:[^ ]*" | awk -F ":" '{print $2}')

Sie können die private IP anzeigen mit:

echo $APP1_PRIVATE_IP

Ausgabe:

Output

Ihre private IP-Adresse ist anders. Notieren Sie sich diese also.

Sie können die private IP auch über das Kontrollfeld digitalocean.com abrufen. Wählen Sie einfach Ihr Droplet und gehen Sie dann zum Abschnitt * Einstellungen *, wie im folgenden Bild dargestellt:

image: https://assets.digitalocean.com/articles/wrk-ubuntu14.04/do-get-private-ip-with-notes.png [Digital Ocean findet die private IP von Droplet]

Starten Sie nun die Anwendung, indem Sie einfach diesen Befehl ausführen:

docker run -d -p $APP1_PRIVATE_IP:3000:3000 --name=http-debugging-application czerasz/http-debugger

Mit dem obigen Befehl wird zuerst das erforderliche Docker-Image heruntergeladen und anschließend ein Docker-Container ausgeführt. Der Container wird im detached mode gestartet, was einfach bedeutet, dass er im Hintergrund ausgeführt wird. Die Option "+ -p $ APP1_PRIVATE_IP: 3000: 3000 " überträgt den gesamten Datenverkehr zum und vom lokalen Container am Port " 3000 " und zur und vom privaten Host-IP am Port " 3000 +".

Ein Diagramm unten beschreibt diese Situation:

image: https://assets.digitalocean.com/articles/wrk-ubuntu14.04/debugging-application-container-overview.png [Visualisierung des Anwendungscontainers debuggen]

Testen Sie nun mit + curl +, ob die Anwendung ausgeführt wird:

curl -i -XPOST http://$APP1_PRIVATE_IP:3000/test -d 'test=true'

Erwartete Ausgabe:

OutputHTTP/1.1 200 OK
X-Powered-By: Express
X-Debug: true
Content-Type: text/html; charset=utf-8
Content-Length: 2
ETag: W/"2-79dcdd47"
Date: Wed, 13 May 2015 16:25:37 GMT
Connection: keep-alive

ok

Die Anwendung ist sehr einfach und gibt nur eine "+ ok " - Nachricht zurück. Jedes Mal, wenn wrk diese Anwendung anfordert, wird eine kleine " ok +" - Nachricht zurückgegeben.

Der wichtigste Teil ist, dass wir durch Analysieren der Anwendungsprotokolle sehen können, welche Anforderungen von Wrk an unsere Anwendung gestellt werden.

Zeigen Sie die Anwendungsprotokolle mit dem folgenden Befehl an:

docker logs -f --tail=20 http-debugging-application

Ihre Beispielausgabe sollte folgendermaßen aussehen:

Output[2015-05-13 16:25:37] Request 1

POST/1.1 /test on :::3000

Headers:
- user-agent: curl/7.38.0
- host: 0.0.0.0:32769
- accept: */*
- content-length: 9
- content-type: application/x-www-form-urlencoded

No cookies

Body:
test=true

Wenn Sie möchten, können Sie dies während der Ausführung Ihrer Benchmark-Tests ausführen lassen. Verlassen Sie den Schwanz mit + CTRL-C +.

Schritt 3 - Installieren Sie wrk

Melden Sie sich beim * wrk1 * -Server an und bereiten Sie sich auf die Installation von wrk vor.

Da wir Docker haben, ist es sehr einfach. Laden Sie einfach das Bild https://registry.hub.docker.com/u/williamyeh/wrk/ [+ williamyeh / wrk +] vom Docker-Registrierungs-Hub mit folgendem Befehl herunter:

docker pull williamyeh/wrk

Mit dem obigen Befehl wird ein Docker-Image heruntergeladen, das wrk enthält. Wir müssen weder wrk erstellen noch zusätzliche Pakete installieren. Um wrk (innerhalb eines Containers) auszuführen, müssen wir nur einen Container basierend auf diesem Image starten, was wir bald tun werden.

Der Download sollte nur wenige Sekunden dauern, da das Bild sehr klein ist - weniger als 3 MB. Wenn Sie wrk direkt auf Ihrer bevorzugten Linux-Distribution installieren möchten, besuchen Sie this wiki page und folgen Sie den Anweisungen.

Wir setzen auch die Variable "+ APP1_PRIVATE_IP +" auf diesem Server. Wir benötigen die private IP-Adresse aus dem Droplet * app1 *.

Exportieren Sie die Variable mit:

export APP1_PRIVATE_IP=

Denken Sie daran, die "++" - IP-Adresse in die private IP-Adresse Ihres * app1 * Droplets zu ändern. Diese Variable wird nur in der aktuellen Sitzung gespeichert. Denken Sie also daran, sie bei der nächsten Anmeldung für die Verwendung von wrk neu festzulegen.

Schritt 4 - Führen Sie einen Wrk-Benchmark-Test durch

In diesem Abschnitt werden wir endlich Wrk in Aktion sehen.

Alle Befehle in diesem Abschnitt sollten auf dem Droplet * wrk1 * ausgeführt werden.

Lassen Sie uns sehen, welche Optionen wrk für uns bietet. Wenn Sie den Wrk-Container nur mit dem Flag "+ - version +" ausführen, wird eine kurze Zusammenfassung seiner Verwendung ausgegeben:

docker run --rm williamyeh/wrk --version

Ausgabe:

Outputwrk 4.0.0 [epoll] Copyright (C) 2012 Will Glozer
Usage: wrk <options> <url>
 Options:
   -c, --connections <N>  Connections to keep open
   -d, --duration    <T>  Duration of test
   -t, --threads     <N>  Number of threads to use

   -s, --script      <S>  Load Lua script file
   -H, --header      <H>  Add header to request
       --latency          Print latency statistics
       --timeout     <T>  Socket/request timeout
   -v, --version          Print version details

 Numeric arguments may include a SI unit (1k, 1M, 1G)
 Time arguments may include a time unit (2s, 2m, 2h)

Nachdem wir uns einen guten Überblick verschafft haben, können wir den Befehl zum Ausführen unseres Tests zusammenstellen. Beachten Sie, dass dieser Befehl noch keine Aktion ausführt, da er nicht im Container ausgeführt wird.

Der einfachste Fall, den wir mit wrk ausführen könnten, ist:

wrk -t2 -c5 -d5s -H 'Host: example.com' --timeout 2s http://$APP1_PRIVATE_IP:3000/

Was bedeutet:

  • + -t2 +: Verwenden Sie * zwei * separate * Threads *

  • + -c5 +: Öffne * sechs Verbindungen * (der erste Client ist Null)

  • + -d5s +: Test für * fünf Sekunden * ausführen

  • + -H 'Host: example.com' +: Übergebe einen + Host + * Header *

  • + - Timeout 2s +: Definiert ein * Timeout von zwei Sekunden *

  • + http: // $ APP1_PRIVATE_IP: 3000 / + Die Zielanwendung lauscht auf + $ APP1_PRIVATE_IP: 3000 +

  • Benchmarking des "+ / +" - Pfades unserer Anwendung

Dies kann auch als sechs Benutzer beschrieben werden, die unsere Homepage wiederholt für fünf Sekunden anfordern.

Die folgende Abbildung zeigt diese Situation:

image: https://assets.digitalocean.com/articles/wrk-ubuntu14.04/wrk-architecture-structure.png [wrk architecture structure]

  • Hier ist der aktuelle Befehl für den Test: *

Führen Sie das beschriebene Szenario in unserem Wrk Docker-Container aus:

docker run --rm williamyeh/wrk -t2 -c5 -d5s -H 'Host: example.com' --timeout 2s http://$APP1_PRIVATE_IP:3000/

Warten Sie einige Sekunden, bis der Test ausgeführt wird, und sehen Sie sich die Ergebnisse an, die wir im nächsten Schritt analysieren werden.

Schritt 5 - Bewerten Sie die Ausgabe

Ausgabe:

OutputRunning 5s test @ http://10.135.232.163:3000
 2 threads and 5 connections
 Thread Stats   Avg      Stdev     Max   +/- Stdev
   Latency     3.82ms    2.64ms  26.68ms   85.81%
   Req/Sec   550.90    202.40     0.98k    68.00%
 5494 requests in 5.01s, 1.05MB read
Requests/sec:   1096.54
Transfer/sec:    215.24KB

  • Aktuelle Konfigurationszusammenfassung:

    Running 5s test @ http://10.135.232.163:3000
 2 threads and 5 connections

    + Hier sehen wir eine kurze Zusammenfassung unserer Benchmark-Konfiguration. Der Benchmark dauerte 5 Sekunden, die IP-Adresse der Benchmark-Maschine ist "+ 10.135.232.163 +" und der Test verwendete zwei Threads.

  • Normale Verteilungsparameter für die Latenz- und Anforderungsstatistik:

    Thread Stats   Avg      Stdev     Max   +/- Stdev
 Latency     3.82ms    2.64ms  26.68ms   85.81%
 Req/Sec   550.90    202.40     0.98k    68.00%

    + Dieser Teil zeigt uns die Normalverteilungsdetails für unseren Benchmark - welche Parameter eine Gaussian function haben würde. + Benchmarks haben nicht immer Normalverteilungen. Daher können diese Ergebnisse irreführend sein. Achten Sie daher immer auf die Werte * Max * und * + / - Stdev *. Wenn diese Werte hoch sind, können Sie damit rechnen, dass Ihre Distribution möglicherweise einen starken Rückgang aufweist.

  • Statistiken zu Anforderungsnummern, übertragenen Daten und Durchsatz:

     5494 requests in 5.01s, 1.05MB read
Requests/sec:   1096.54
Transfer/sec:    215.24KB

    + Hier sehen wir, dass wrk während der Zeit von "+ 5.01 " Sekunden " 5494 " Anfragen ausführen und " 1.05MB " Daten übertragen konnte. Kombiniert mit einfacher Mathematik (" Gesamtzahl der Anfragen / Benchmark-Dauer") erhalten wir das Ergebnis von "+ 1096,54 +" Anfragen pro Sekunde.

Je mehr Clients Sie festlegen, desto weniger Anforderungen sollten Sie im Allgemeinen pro Sekunde erhalten. Die Latenz wird ebenfalls zunehmen. Dies liegt daran, dass die Anwendung stärker ausgelastet ist.

  • Welche Ergebnisse sind am besten? *

Ihr Ziel ist es, die "+ Requests / sec " so hoch wie möglich und die " Latency +" so niedrig wie möglich zu halten.

Im Idealfall sollte die Latenz nicht zu hoch sein, zumindest nicht für Webseiten. Das Limit für die Ladezeit einer Seite mit Assets ist optimal, wenn es sich um * zwei Sekunden * oder weniger handelt.

Jetzt werden Sie sich wahrscheinlich fragen: Ist "550.90 Requests / sec +" mit einer Latenz von " 3,82 ms +" ein gutes Ergebnis? Leider gibt es keine einfache Antwort. Es hängt von vielen Faktoren ab:

  • Anzahl der Kunden, wie wir zuvor besprochen haben

  • Serverressourcen - ist es eine große oder kleine Instanz?

  • Anzahl der Maschinen, die die Anwendung bedienen

  • Art Ihres Dienstes - Ist es ein Cache, der statische Dateien liefert, oder ein Ad-Server, der dynamische Antworten liefert?

  • Datenbanktyp, Größe des Datenbankclusters, Art der Datenbankverbindung

  • Anforderungs- und Antworttyp - handelt es sich um eine kleine AJAX-Anforderung oder einen fetten API-Aufruf?

  • Und viele andere

Schritt 6 - Maßnahmen zur Verbesserung der Latenz ergreifen

Wenn Sie mit Ihrer Serviceleistung nicht zufrieden sind, können Sie:

  • Optimieren Sie Ihren Service - überprüfen Sie Ihren Code und sehen Sie, was effizienter gemacht werden kann

  • Überprüfen Sie Ihre Datenbank, um festzustellen, ob dies Ihr Engpass ist

  • Vertikal skalieren - Fügen Sie Ihrem Computer Ressourcen hinzu

  • Horizontal skalieren - Fügen Sie eine weitere Instanz Ihres Dienstes hinzu und fügen Sie sie dem Load Balancer hinzu

  • Fügen Sie eine Caching-Ebene hinzu

Weitere Informationen zu Anwendungsverbesserungen finden Sie unter 5 Möglichkeiten zur Verbesserung Ihrer Setup des Produktionswebanwendungsservers.

Vergessen Sie nicht, Ihren Service zu bewerten, nachdem Sie Änderungen daran vorgenommen haben. Nur dann können Sie sicher sein, dass sich Ihr Service verbessert hat.

Das ist es, könnte man meinen, wenn es diese Lua-Sache nicht gäbe …​

Simulieren Sie erweiterte HTTP-Anforderungen mit Lua-Skripten

Da wrk einen eingebauten LuaJIT (Just-In-Time-Compiler für Lua) hat, kann es mit Lua-Skripten erweitert werden. Wie bereits in der Einleitung erwähnt, bietet dies eine Menge Funktionen für die Arbeit.

Die Verwendung eines Lua-Skripts mit wrk ist einfach. Hänge einfach den Dateipfad an das + -s + Flag an.

Da wir Wrk in Docker verwenden, müssen wir diese Datei zuerst für den Container freigeben. Dies kann mit der Docker-Option "+ -v +" erreicht werden.

Teile eines Lua-Skripts für wrk

In generischer Form könnte der gesamte Befehl unter Verwendung eines Skripts mit dem Namen "+ test.lua +" folgendermaßen aussehen:

docker run --rm -v `pwd`/scripts:/scripts williamyeh/wrk -c1 -t1 -d5s -s /scripts/test.lua http://$APP1_PRIVATE_IP:3000

Wir haben den Befehl wrk und seine Optionen in einem früheren Schritt erläutert. Dieser Befehl fügt nicht zu viel hinzu. Nur der Pfad zum Skript und einige zusätzliche Befehle, die Docker mitteilen, wie es außerhalb des Containers zu finden ist.

Das Flag "+ - rm +" entfernt den Container nach dem Anhalten automatisch.

Aber wissen wir eigentlich, wie man ein Lua-Skript schreibt? Fürchte dich nicht; Sie werden es mit Leichtigkeit lernen. Wir gehen hier auf ein einfaches Beispiel ein und Sie können Ihre eigenen erweiterten Skripts selbst ausführen.

Lassen Sie uns zunächst über die vorgegebene Skriptstruktur sprechen, die die interne Logik von wrk widerspiegelt. Das folgende Diagramm zeigt es für einen Thread:

image: https://assets.digitalocean.com/articles/wrk-ubuntu14.04/lua-cycle.png [wrk Lua scripting cycle]

wrk führt die folgenden Ausführungsphasen aus:

  • * Löse * die IP-Adresse der Domain auf

  • Beginnen Sie mit dem Thread * setup *

  • Führen Sie die * Stresstest * -Phase durch, die als * Running * -Phase bezeichnet wird

  • Der letzte Schritt heißt einfach * erledigt *

Wenn Sie mehrere Threads verwenden, haben Sie eine Auflösungsphase und eine Fertigstellungsphase, aber zwei Einrichtungsphasen und zwei Ausführungsphasen:

image: https: //assets.digitalocean.com/articles/wrk-ubuntu14.04/lua-cycle-threads.png [wrk Lua-Skriptzyklus für zwei Threads]

Zusätzlich kann die * laufende Phase * in drei Schritte unterteilt werden: * init *, * request * und * response *.

image: https://assets.digitalocean.com/articles/wrk-ubuntu14.04/lua-cycle-running-phase.png [wrk Lua-Skriptzyklus - Ausführungsphase]

Gemäß den dargestellten Diagrammen und der documentation können in einem Lua-Skript die folgenden Methoden verwendet werden:

  • + setup (thread) +: Wird ausgeführt, wenn alle Threads initialisiert, aber noch nicht gestartet wurden. Dient zum Übergeben von Daten an Threads

  • + init (args) +: Wird aufgerufen, wenn jeder Thread initialisiert wird + Diese Funktion empfängt zusätzliche Befehlszeilenargumente für das Skript, die durch "+ - +" von den Wrk-Argumenten getrennt werden müssen. + Beispiel:

wrk -c3 -d1s -t2 -s /scripts/debug.lua http://$APP1_PRIVATE_IP:3000 -- debug true

  • + request () +: Muss das HTTP-Objekt für jede Anfrage zurückgeben. In dieser Funktion können Sie die Methode, die Überschriften, den Pfad und den Text ändern + Verwenden Sie die Hilfsfunktion + work.format, um das Anforderungsobjekt zu formen. + Beispiel:

return wrk.format(method, path, headers, body)

  • + Antwort (Status, Header, Body) +: Wird aufgerufen, wenn die Antwort zurückkommt

  • + erledigt (Zusammenfassung, Latenz, Anforderungen) +: Wird ausgeführt, wenn alle Anforderungen abgeschlossen und Statistiken berechnet wurden + Innerhalb dieser Funktion stehen folgende Eigenschaften zur Verfügung:

Property

Description

summary.duration

run duration in microseconds

summary.requests

total completed requests

summary.bytes

total bytes received

summary.errors.connect

total socket connection errors

summary.errors.read

total socket read errors

summary.errors.write

total socket write errors

summary.errors.status

total HTTP status codes > 399

summary.errors.timeout

total request timeouts

latency.min

minimum latency value reached during test

latency.max

maximum latency value reached during test

latency.mean

average latency value reached during test

latency.stdev

latency standard deviation

latency:percentile(99.0)

99th percentile value

latency[i]

raw latency data of request i

Jeder Thread hat seinen eigenen Lua-Kontext und in ihm seine eigenen lokalen Variablen.

Im Folgenden werden einige praktische Beispiele vorgestellt. Weitere nützliche Benchmarking-Skripte finden Sie im Verzeichnis https://github.com/wg/wrk/tree/master/scripts [+ scripts +] des wrk-Projekts.

Beispiel: + POST + Anfragen

Beginnen wir mit dem einfachsten Beispiel, in dem wir eine "+ POST" -Anforderung simulieren.

"+ POST" -Anfragen werden normalerweise verwendet, um Daten an den Server zu senden. Dies könnte zum Benchmarking verwendet werden:

  • HTML-Formular-Handler: Verwenden Sie die Adresse, die im Attribut "+ action +" Ihres HTML-Formulars enthalten ist:

    <form action="/login.php">
...
</form>

  • + POST + API-Endpunkte: Wenn Sie über eine restful API verfügen, verwenden Sie den Endpunkt, auf dem Sie Ihren Artikel erstellen:

    POST /articles

Beginnen Sie mit dem Erstellen einer + scripts / post.lua + Datei auf dem * wrk1 * Droplet.

cd ~
mkdir scripts
nano scripts/post.lua

Fügen Sie dazu den folgenden Inhalt hinzu:

post.lua

wrk.method = "POST"
wrk.body   = "login=sammy&password=test"
wrk.headers["Content-Type"] = "application/x-www-form-urlencoded"

Dieses Skript ist sehr einfach und wir haben noch keine der genannten Methoden verwendet. Wir haben gerade die globalen Objekteigenschaften "+ wrk +" geändert.

Wir haben die Anforderungsmethode in "+ POST " geändert, einige Anmeldeparameter hinzugefügt und den Header " Content-Type +" für die Verwendung von HTML-Formularen vom Typ MIME angegeben.

Bevor wir mit dem Benchmark beginnen, sehen Sie in der folgenden Abbildung, wie sich das Skript, der Docker-Container und der App-Server verhalten:

image: https://assets.digitalocean.com/articles/wrk-ubuntu14.04/container-overview.png [Docker-Container-Visualisierung]

Jetzt der Moment der Wahrheit - vergleiche die Anwendung mit diesem Befehl (auf dem * wrk1 * Droplet ausführen):

docker run --rm -v `pwd`/scripts:/scripts williamyeh/wrk -c1 -t1 -d5s -s /scripts/post.lua http://$APP1_PRIVATE_IP:3000

Ausgabe:

OutputRunning 5s test @ http://10.135.232.163:3000
 1 threads and 1 connections
 Thread Stats   Avg      Stdev     Max   +/- Stdev
   Latency     1.04ms  718.38us  12.28ms   90.99%
   Req/Sec     1.02k   271.31     1.52k    66.00%
 5058 requests in 5.00s, 0.97MB read
Requests/sec:   1011.50
Transfer/sec:    198.55KB

Die Ausgabe ähnelt der, die wir zuvor gesehen haben.

Beachten Sie, dass wir hier ein Benchmarking mit nur einer Verbindung durchführen. Dies entspricht einer Situation, in der sich nur ein Benutzer kontinuierlich anmelden möchte und den Benutzernamen und das Kennwort weitergibt. Hierfür werden keine CSS-, Bild- oder JavaScript-Dateien angefordert.

Für ein realistischeres Szenario sollten Sie die Anzahl der Clients und Threads erhöhen und gleichzeitig den Latenzparameter beobachten, um festzustellen, wie schnell die Anwendung die Benutzeranmeldeinformationen validieren kann.

Beispiel: Mehrere URL-Pfade

Eine weitere häufige Anforderung besteht darin, mehrere Pfade einer Anwendung gleichzeitig zu testen.

Erstellen wir eine Datei mit dem Namen "+ paths.txt " in einem " data +" - Verzeichnis und fügen alle Pfade hinzu, die wir während unseres Benchmarks verwenden möchten.

cd ~
mkdir data
nano data/paths.txt

Nachfolgend finden Sie ein Beispiel für "+ data / paths.txt +":

paths.txt

/feed.xml
/contact/
/about/
/blog/
/2015/04/21/nginx-maintenance-mode/
/2015/01/06/vagrant-workflows/
/2014/12/10/top-vagrant-plugins/

Dann greifen Sie auf dieses einfache Skript zu und speichern Sie es unter + scripts / multiple-url-paths.lua +:

multiple-url-paths.lua

-- Load URL paths from the file
function load_url_paths_from_file(file)
 lines = {}

 -- Check if the file exists
 -- Resource: http://stackoverflow.com/a/4991602/325852
 local f=io.open(file,"r")
 if f~=nil then
   io.close(f)
 else
   -- Return the empty array
   return lines
 end

 -- If the file exists loop through all its lines
 -- and add them into the lines array
 for line in io.lines(file) do
   if not (line == '') then
     lines[#lines + 1] = line
   end
 end

 return lines
end

-- Load URL paths from file
paths = load_url_paths_from_file("/data/paths.txt")

print("multiplepaths: Found " .. #paths .. " paths")

-- Initialize the paths array iterator
counter = 0

request = function()
 -- Get the next paths array element
 url_path = paths[counter]

 counter = counter + 1

 -- If the counter is longer than the paths array length then reset it
 if counter > #paths then
   counter = 0
 end

 -- Return the request object with the current URL path
 return wrk.format(nil, url_path)
end

Während dieses Tutorial nicht versucht, Lua-Skripte im Detail zu lehren, können Sie sich anhand der Kommentare im Skript einen guten Eindruck davon verschaffen, was es bewirkt.

Das Skript "+ multiple-url-paths.lua " öffnet die Datei " / data / paths.txt ". Wenn diese Datei Pfade enthält, werden diese in einem internen Array " path +" gespeichert. Dann wird mit jeder Anforderung der nächste Pfad genommen.

Verwenden Sie zum Ausführen dieses Benchmarks den folgenden Befehl (auf dem Droplet * wrk1 * ausführen). Sie werden feststellen, dass wir einige Zeilenumbrüche hinzufügen, um das Kopieren zu vereinfachen:

docker run --rm \
          -v `pwd`/scripts:/scripts \
          -v `pwd`/data:/data \
          williamyeh/wrk -c1 -t1 -d5s -s /scripts/multiple-url-paths.lua http://$APP1_PRIVATE_IP:3000

Ausgabe:

Outputmultiplepaths: Found 7 paths
multiplepaths: Found 7 paths
Running 5s test @ http://10.135.232.163:3000
 1 threads and 1 connections
 Thread Stats   Avg      Stdev     Max   +/- Stdev
   Latency     0.92ms  466.59us   4.85ms   86.25%
   Req/Sec     1.10k   204.08     1.45k    62.00%
 5458 requests in 5.00s, 1.05MB read
Requests/sec:   1091.11
Transfer/sec:    214.17KB

Erweiterte Anfragen mit JSON und YAML

Jetzt könnten Sie denken, dass auch andere Benchmarking-Tools diese Art von Tests durchführen können. Wrk kann jedoch auch erweiterte HTTP-Anforderungen im JSON- oder YAML-Format verarbeiten.

Sie können beispielsweise eine JSON- oder YAML-Datei laden, in der jede Anforderung ausführlich beschrieben wird.

Der Autor hat ein erweitertes Beispiel mit einer JSON-Anfrage auf the author’s tech blog veröffentlicht.

Sie können mit wrk und Lua jede Art von HTTP-Anfrage vergleichen, die Sie sich vorstellen können.

Fazit

Nachdem Sie diesen Artikel gelesen haben, sollten Sie in der Lage sein, wrk zum Benchmarking Ihrer Anwendungen zu verwenden. Als Randnotiz können Sie auch die Schönheit von Docker erkennen und feststellen, wie das Einrichten von Anwendungen und Testumgebungen auf ein Minimum reduziert werden kann.

Schließlich können Sie mit erweiterten HTTP-Anforderungen mithilfe von Lua-Skripten mit wrk noch einen Schritt weiter gehen.

Related