WordPress unleashed: Performance Tests

Performance Tests ohne Cache

Im Folgenden wird ein WordPress Blog ohne jegliche Plugins und Caching getestet. Dies aus dem Grund, weil ich die Performance Unterschiede zwischen PHP-FPM und HHVM darlegen möchte. Dabei ist zu beachten, dass HHVM bereits compilierte Inhalte cacht. Das bedeutet, dass der zweite Testdurchlauf immer deutlich schneller, als der erste sein wird. Die Tests werden von einer zweiten VM bzw. direkt von meinem Desktop gestartet.

ApacheBench

Ein einfacher Lasttest kann mit ApacheBench gefahren werden. Dieser ist jedoch nicht in der Lage Last zu erzeugen, der Userverhalten ähnelt. Vielmehr wird eine Bestimmte Seite mit einer zu bestimmenden Anzahl von Anfragen und gleichzeitigen Verbindungen bombardiert. Die Installation läuft mit

Der Aufruf zum Testen der Landing Page ist ab -k -n 1000 -c 50 http://192.168.178.47/. Es werden 1000 Aufrufe mit 50 gleichzeitigen Verbindungen gemacht.

Bei PHP-FPM kommt man auf:

HHVM im ersten Durchlauf:

HHVM im zweiten Durchlauf, bei dem die Inhalte nun gecacht sind:

JMeter

Nun geht es daran mittels JMeter ein aussagekräftigeres Test Szenario zu bauen. Ich werde auch hier mit 50 gleichzeitigen Verbindungen arbeiten. Dabei werden verschiedene Teile des Blogs aufgerufen. Die Config könnt ihr hier downloaden und für eure Zwecke anpassen.

Das Ergebnis mit JMeter spiegelt im Großen und Ganzen das ApacheBench Ergebnis wider. Durch die genauere Analyse fällt auf, das HHVM deutlich besser skaliert. So kann man sehen, dass bei PHP-FPM die Requests alle relativ gleich lange brauchen, während es unter HHVM je nach Anfragentyp deutliche Unterschiede gibt. Alle Anfragen, die nicht gegen Blog Post und Blog Post Übersichten gehen, sind deutlich schneller, als der Rest.

PHP-FPM Ergebnisse

jmeter_fpm_summary

jmeter_fpm_requests_time

jmeter_fpm_response_time

HHVM Ergebnisse

jmeter_hhvm_summary

jmeter_hhvm_requests_time

jmeter_hhvm_response_time

Performance Tests Elasticsearch

Mittels ApacheBench hatte ich vorab einen Test ohne Elasticsearch gegen den HHVM Vhost gefahren. Beide Ergebnisse sind aus dem zweiten Durchlauf. Die Parameter waren ab -k -n 500 -c 10 http://192.168.178.48/?s=demo. Man kann sehen, dass Elasticsearch vor allem eine funktionale Erweiterung ist. Erst bei großen Setups, bei denen Suchen, den SQL Server an die Grenzen bringen, kann man durch Elasticsearch an Geschwindigkeit gewinnen.

Mit der normalen WordPress Suche waren es:
Time taken for tests: 14.940 seconds
Complete requests: 500
Failed requests: 0
Write errors: 0
Keep-Alive requests: 0
Total transferred: 16269500 bytes
HTML transferred: 16049000 bytes
Requests per second: 33.47 [#/sec] (mean)
Time per request: 298.796 [ms] (mean)
Time per request: 29.880 [ms] (mean, across all concurrent requests)
Transfer rate: 1063.48 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.5 0 10
Processing: 158 297 22.3 299 360
Waiting: 157 292 22.2 294 352
Total: 158 298 22.3 300 361

Percentage of the requests served within a certain time (ms)
50% 300
66% 307
75% 311
80% 314
90% 321
95% 331
98% 342
99% 350
100% 361 (longest request)

Bei der Hinzunahme von Elasticsearch sieht es dann wie folgt aus:

Time taken for tests: 15.344 seconds
Complete requests: 500
Failed requests: 0
Write errors: 0
Keep-Alive requests: 0
Total transferred: 15932000 bytes
HTML transferred: 15711500 bytes
Requests per second: 32.59 [#/sec] (mean)
Time per request: 306.884 [ms] (mean)
Time per request: 30.688 [ms] (mean, across all concurrent requests)
Transfer rate: 1013.97 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.3 0 2
Processing: 124 305 25.9 306 379
Waiting: 124 300 25.5 300 374
Total: 125 306 26.0 306 381

Percentage of the requests served within a certain time (ms)
50% 306
66% 317
75% 322
80% 325
90% 336
95% 346
98% 354
99% 363
100% 381 (longest request)

Benchmark mit Cache von extern

Nachdem ich alle Dienste neu gestartet hatte

wird abermals ein ApacheBench mit den Parametern ab -k -n 1000 -c 50 http://192.168.178.48/ gestartet
Time taken for tests: 1.369 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 1000
Total transferred: 60199000 bytes
HTML transferred: 60050000 bytes
Requests per second: 730.30 [#/sec] (mean)
Time per request: 68.465 [ms] (mean)
Time per request: 1.369 [ms] (mean, across all concurrent requests)
Transfer rate: 42933.07 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 1.9 0 10
Processing: 2 60 72.2 28 604
Waiting: 0 44 63.4 13 338
Total: 2 61 72.4 30 604

Percentage of the requests served within a certain time (ms)
50% 30
66% 68
75% 88
80% 99
90% 128
95% 249
98% 334
99% 348
100% 604 (longest request)

Benchmark mit Cache von intern

Ich kannte die Zahlen von anderen Systemen und bin deswegen etwas ins Grübeln gekommen. Ich vermutete die Netzwerkschnittstelle der Virtualisierung als Flaschenhals und habe die gleiche Benchmark von der VM aus gestartet, auf der auch WordPress läuft. Das Ergebnis war gleich ein ganz anderes. Mit einer Übertragungsrate von ca. 1 GigaByte/S werden deutlich höhere Durchsätze erreicht.

ab -k -n 100000 -c 200 http://192.168.178.48/

Time taken for tests: 55.778 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 99095
Total transferred: 6029395475 bytes
HTML transferred: 6005000000 bytes
Requests per second: 1792.83 [#/sec] (mean)
Time per request: 111.556 [ms] (mean)
Time per request: 0.558 [ms] (mean, across all concurrent requests)
Transfer rate: 105563.00 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.6 0 21
Processing: 1 111 66.1 94 1148
Waiting: 0 107 67.1 90 1147
Total: 1 111 66.1 94 1148

Percentage of the requests served within a certain time (ms)
50% 94
66% 118
75% 139
80% 155
90% 201
95% 225
98% 268
99% 316
100% 1148 (longest request)


Weiter geht es mit WordPress unleashed: Nginx absichern

Alle Teile dieser Serie

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.