(Stand 30.10.2016)
Die Ausstattung des neuen Linux V20 vServers:
2 vCores (Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz – Effektiver Takt 1998.828 MHz)
4 GB Maxx-RAM 2 GB RAM garantiert
300 GB HDD
Als Vergleich zum Einordnen der Ergebnisse dient ein kleiner Strato-Hardwareserver:
4 CPU Cores (Quad-Core AMD Opteron(tm) Processor 1385 2700.000 MHz)
4 GB RAM
1 TB 7200 rpm HDD (Raid 1)
Nach einigen negativen Erfahrungen mit Strato vServer und ernüchternden Benchmark-Werten von Strato vServer wollte ich mir die neuen Strato V20 VServer anschauen, um herauszufinden, ob sich in Sachen Performance und Stabilität etwas getan hat.
Dazu wurden einige Benchmarks sowohl mit dem neuen vServer V20 als auch mit dem Hardwareserver durchgeführt:
SysBench MySQL
sysbench –test=oltp –oltp-table-size=1000000 –mysql-db=test –mysql-user=test –mysql-password=PASSWORD –max-time=60 –oltp-read-only=off –max-requests=0 –num-threads=[ANZAHL THREADS] run
| Anzahl Threads | #Transactions vServer V20 Linux | #Transactions Hardwareserver |
| 2 | 2805 (46.73 per sec.) | 1271 (21.16 per sec.) |
| 4 | 4842 (80.65 per sec.) | 2596 (43.23 per sec.) |
| 8 | 8777 (145.83 per sec.) | 4984 (82.98 per sec.) |
| 16 | 13704 (228.29 per sec.) | 11297 (188.14 per sec.) |
| 32 | 18073 (300.73 per sec.) | 18978 (315.95 per sec.) |
| 64 | 19828 (330.07 per sec.) | 28705 (478.04 per sec.) |
| 128 | 20271 (337.04 per sec.) | 33187 (532.58 per sec.) |
SysBench CPU
sysbench –test=cpu –cpu-max-prime=10000 –num-threads=[Anzahl THREADS] run
| Anzahl Threads | Dauer(s) vServer V20 Linux | Dauer(s) Hardwareserver |
| 1 | 11.0606s | 13.1548s |
| 2 | 7.6546s | 6.5501s |
| 4 | 7.6804s | 3.3243s |
| 8 | 7.6758s | 3.2985s |
| 16 | 15.1823s | 3.3063s |
IO Test mit dd
Schreiben eines 1 GB Files mit dd
dd if=/dev/urandom of=/tmp/benchfile bs=1024K count=1024
| Anzahl Threads | Dauer vServer V20 Linux | Dauer Hardwareserver |
| 2 | 70,5767s (15,2 MB/s) | 90,5309s (11,9 MB/s) |
Webserver Benchmark mit AB (Apache HTTP server benchmarking tool)
ab -kc [Concurrency Level] -t 30 http://www.WEBSEITE.de/
| Concurrency Level | #Requests vServer V20 Linux | #Requests Hardwareserver |
| 5 | 1952 | 2838 |
| 10 | 1968 | 2778 |
| 25 | 1796 | 2722 |
Anscheinend hat Strato nicht nur die Probleme mit den vServern in den Griff bekommen, sondern auch an der Performanceschraube gedreht.
Was auffällt, sind die relativ guten SysBench CPU Werte bei kleiner Threadanzahl im Vergleich zu dem Hardwareserver. Auch scheint jetzt endlich die schon lange beworbene „SSD-Power“ bei den Kunden angekommen zu sein. Das zeigen vor allem die im Vergleich zu dem Hardwareserver besseren SysBench MySQL Werte bei niedrigeren Thread-Anzahlen. Auch bei dem IO Test mit dd zeigt der vServer V20 jetzt bessere Werte als der Hardwareserver.
Die Apache Benchmark Werte zeigen endgültig, dass die Strato vServer um Größenordnungen leistungsfähiger geworden sind im Vergleich zu 2015.
Die insgesamt wesentlich höheren Werte bei Apache Bench im Vergleich zum letzten vServer Apache Benchmark kommen von dem nun eingeschalteten PHP opcode Cache, der gerade bei TYPO3 einiges an Performance bringt.
Der einzige Wermutstropfen, der den Einsatzzweck des V20 vServer schmälert, ist die geringe Inode Quota von 800000. Selbst die älteren vServer hatten wenigstens 1000000 Inodes. Bei dem billigsten netcup vServer, der weniger als die Hälfte des kleinsten Strato vServers kostet, bekommt man immerhin 2511552 Inodes, also das 2,5-fache. Wer viele Inodes benötigt, kommt um einen Hardwareserver nicht herum.
Die Ergebnisse noch einmal zusammengefasst:
+ Sehr gute SysBench CPU Leistung
+ Sehr gute SysBench MySQL Werte
+ Gute Apache Bench Werte
+ Großzügiger Festplattenplatz
– Sehr geringe INODE Quota im Vergleich zu Hardwareservern
Was bewirkt die INODE Quota. Wann ist ein hoher Wert (Wert = subjektiv) erforderlich? Spielt sie eine Rolle z.B. im praktischen Einsatz z.B. einer WordPress-Website mit einem Benutzer und vielen Medien (Foto-Galerien)?
Die Inodeproblematik kann man bei dem geschilderten Anwendungsfall vernachlässigen. 800000 Inodes sind ja ungefähr 800000 Dateien. Das müssten ja schon extrem viel Fotos sein, um da an die Grenze zu kommen. Schneller zum Problem können die Inodes werden, wenn man rsnapshot für das Backup seines Servers nimmt. Für jede Version einer Datei (stündliche, tägliches, wöchentliche und monatliche Backups) wir ein symbolischer Link angelegt der ein Inode verbraucht. So kommt es ganz schnell zu einem Inodeverbrauch der die Anzahl der eigentlichen Dateien um ein vielfaches überschreitet.
Verstehe das Problem nicht. Inodes sind doch Sache des installierten Betriebssystems und damit zu 100% kundenseitig konfigurierbar. Was ist die Botschaft dieses Artikels?
Strato V-Server waren zu der Zeit mit Virtuozzo Virtual Private Server (VPS) realisiert. Dort war die Inode-Anzahl als Quota definiert. Als Kunde hatte man keinen Einfluss auf die Inodes-Quota.