Test Strato V-Server Version Linux V20

(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

2 thoughts on “Test Strato V-Server Version Linux V20

  1. Wolle Ing

    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)?

  2. mediamill Beitragsautor

    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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.