Hallo zusammen! Diesmal melde ich mich mit einer dreiteiligen Serie, in der ich auf einen Game-, Root-, Voice- und vServer-Anbieter eingehen und seine Angebote testen werde. Es handelt sich hierbei um Rock-Server. Der erste Teil wird einer der größten werden, da ich einen Linux-vServer von besagtem Anbieter testen werde.

Bei meinen Tests werde ich versuchen auf alle gängigen Faktoren einzugehen, die bei einem vServer für Web-Anwendungen oder Spiele (CS:GO etc.) relevant sind. Dazu zählen:

• initiale Konfiguration
• Festplatten-IO
• Arbeitsspeicher-Geschwindigkeit
• CPU-Leistung
• Netzwerk-Datendurchsatz
• Ping

Der vServer, welchen ich ausprobieren durfte, hat folgende Eigenschaften:

• 40 GB Festplattenspeicher
• 2 GB RAM
• 2 vCores von einer Xeon E3-1240v3  CPU
• 100 Mbit Anbindung
• Debian 7.1 vorinstalliert (andere Linux-Distros sind schnell über das Webinterface installiert, zur Auswahl stehen neben Debian noch SuSE, Ubuntu, Fedora und CentOS)

Bei den Benchmarks diente als Vergleichsobjekt, und ich möchte hier anmerken, dass es mir leid tut, dass ich nichts “ordentliches” zum vergleichen habe, mein ThinkPad T61 mit folgender Ausstattung:

• 128 GB SanDisk SSD
• T8100 mit 2×2,1GHz
• 2 GB DDR2 RAM
• Debian 7.4

Gerne könnt ihr per Kommentar auch nachträglich für diesen und weitere Tests Benchmarks vorschlagen!

Initiale Konfiguration

Vom Rock-Server-Webinterface bin ich absolut begeistert. Es ist schick, simpel aufgebaut und hat alle Funktionen, die man von einem Webinterface erwartet. Der größte Pluspunkt, den ich an das Webinterface verteile ist die Tatsache, dass es alle Server-Angelegenheiten in einem Interface vereint. Es stellt also kein Problem dar, bei Rock-Server mehrere Produkte gleichzeitig zu haben, da alles bequem über das gleiche Interface zu bedienen ist. Ich finde das sehr lobenswert, da ich schon viele andere Anbieter gesehen habe, die völlig lieblos irgendwelche Hosting-Panels und bei Serverlösungen mitgelieferten Interfaces anbieten, wobei man am Ende einen ganzen Stapel an Zugangsdaten herumliegen hat und selten alles schnell wiederfindet.

Nachdem ich das Webinterface inspiziert hatte, ging ich dazu über, das Root-Passwort des bereits erstellten Servers zu ändern und mich einzuloggen. Das funktionierte auch einwandfrei bis zu dem Punkt, an dem ich den Hostname anstatt der IP (134.255.237.6) des Systems eingegeben hatte. Denn der war scheinbar mit einer anderen IP (134.255.238.6) verknüpft. Solch Problem kann unter anderem dazu führen, dass von diesem Server versendete Mails bei großen Mailern abgewiesen werden, die nämlich überprüfen ob hinter einem Hostname sich wirklich die IP verbirgt, von der die Mail kam. Das ist ein Schutzmechanismus gegen Spam und anderen Schindluder.
Da der Login mit der IP funktionierte, tat das Problem mit dem merkwürdigen Hostname meinem Vorhaben, den Server zu testen, jedoch erstmal keinen Abbruch. [Paste]

Auf dem schön sauberen, frischen System überprüfte ich mit “cat /proc/cpuinfo” welcher Prozessor sich hinter dem vServer verbarg. Anders als in der Angebotsbeschreibung auf der Startseite handelte es sich um einen i7-3770 und damit einen Desktop-Prozessor welcher in den meisten Fällen von der Qualität und Stabilität nicht an einen Server-Prozessor herankommt. In Anbetracht dessen, dass der ganze vServer nur 12 Euro im Monat kostet, ist dies jedoch zu verkraften. Ein Hinweis, dass die CPU des Hostsystems variieren kann, wäre dennoch schön gewesen. [Paste]

Das Ausführen des Befehls “hostname” brachte hervor, dass der vServer auch noch nicht seinen korrekten FQDN weiß. Das ist ein typisches Problem, welches ich von OpenVZ kenne. Dieses tritt bei vielen Anbietern auf und ist leicht zu beheben. Ich wollte hier nur nochmal darauf hinweisen, dass sowas vor dem Produktivbetrieb durch den Benutzer oder den Anbieter behoben werden sollte, da gleiches Problem droht wie im vor-vorherigen Absatz beschrieben (exteren Mailserver könnten mangels korrektem FQDN den Empfang blocken). [Paste]

Ansonsten handelte es sich um ein völlig normales Debian, vermutlich ein von Rock-Server selbst erstelltes Image oder ein OpenVZ-Fertig-Image. Beim Kernel handelte es sich um 2.6.32-042stab083.2 und damit einen relativ aktuellen OpenVZ-Kernel von Anfang November 2013.

Festplatten-IO

Den Durchsatz der Festplatten bei verschiedenen Szenarien testete ich mit sysbench. Dabei testete ich folgende Szenarien, in denen mit Daten hantiert wird:

• seqwr (sequenzielles Schreiben)
• seqrewr (sequenzielles Lesen/Schreiben)
• seqrd (sequenzielles Lesen)
• rndrd (zufälliges Lesen)
• rndwr (zufälliges Schreiben)
• rndrw (zufälliges Lesen/Schreiben)

Der Einfachheit und Veranschaulichung halber wollte ich ein Diagramm erstellen, bei dem ich die Raten meiner SSD mit den Raten der virtuellen Festplatte des VPS vergleiche. Das Problem: sysbench funktioniert scheinbar nicht immer ganz korrekt und liest Daten aus dem RAM. Oder irgendwas anderes. Jedenfalls sahen die Übertragungsraten an manchen Stellen (Lesen) äußerst merkwürdig aus:

Modus – VPS – Notebook:
seqwr – 67,25 MB/s – 117,73 MB/s
seqrewr – 58,58 MB/s – 123,26 MB/s
seqrd – 8854,60 MB/s – 134,39 MB/s
rndrd – 7698,20 MB/s – 117,93 MB/s
rndwr – 1,50 MB/s – 18,14 MB/s
rndrw – 2,10 MB/s – 35,31 MB/s

Da bemerkt man schon starke Unterschiede. Ich wage mir fast gar nicht zu sagen, dass in einem späteren rndwr-Test die Schreibrate bei 420 KB/s und die durchschnittliche Reaktionszeit bei fast 400 ms lag. Kürzlich habe ich gelernt, dass 400 ms etwa der Wert sind, bei dem Telefonate unbeholfen wirken (durchschnittlicher Ping von Deutschland nach Australien liegt bei 380 ms je nach Standort).

Was mit den Lese-Raten los ist/war kann ich beim besten Willen nicht sagen. Durch Neustarten und cleanup wurde sichergestellt, dass die Daten nicht aus dem RAM kommen. Kleine bis große Dateien habe ich ausprobiert. Ich tippe eher auf ein Problem mit sysbench. Das werde ich im Anschluss an diesen Artikel mal prüfen und eventuelle Ergebnisse hier schreiben. [Paste]

Arbeitsspeicher-Geschwindigkeit

Dem vServer ist ein fester Wert an RAM zugewiesen. In meinem Fall sind es 2 GB die ich gänzlich nutzen kann (kein nur-Burst oder ähnliches). Getestet habe ich die Geschwindigkeit des RAM auch wieder mit sysbench. Hierbei erreichte der 2 GB große DDR2-800 RAM meines ThinkPads bei einem nutzbaren Thread 235,65 MB pro Sekunde, bei beiden Threads 335,11 MB pro Sekunde. Das die vergleichsweise kleine und alte Maschine mit einem aktuellen Server nicht mithalten kann, war ja klar. Dennoch war ich selbst beeindruckt, als ich die Raten des vServers sah. So beträgt die Datenrate bei einem Thread satte 2882,01 MB pro Sekunde, bei beiden Threads 4518,62 MB pro Sekunde. Eine satte Geschwindigkeit.

Wenn es an die Zugriffszeiten geht, liegt der vServer ebenfalls weit vorn. So sind, da die Zugriffszeiten auf den RAM normalerweise im Nanosekunden-Bereich liegen, keine Messwerte in Millisekunden bei sysbench vorhanden. Hin und wieder gab es kurze Aussetzer mit mal 10, mal 0,2 ms. Der Durchschnittswert lag aber darunter. Beim ThinkPad hingegen sah die Sache ähnlich aus, hin und wieder gab es Hacken bei 20,21 und mal bei 10 ms. [Paste]

CPU-Leistung

Die berauschenden Werte des RAM-Tests wurden durch den CPU-Test wieder ein bisschen abgeschwächt. So erreicht das VPS bei Ausnutzung beider Threads und einer in sysbench festgelegten Primzahl von 20000 sein Ergebnis in 12,6267 Sekunden. Die Reaktionszeit liegt dabei bei durchschnittlich 6,6 Millisekunden. Das Vergleichssystem, mein ThinkPad, kommt hierbei trotz laufender Anwendungen wie Firefox und Thunderbird auf 15,7030 Sekunden bei Reaktionszeiten von durchschnittlich 3,14 Millisekunden. [Paste]

Netzwerk-Datendurchsatz

Und schon sind wir beim wichtigsten Teil eines in einem Rechenzentrum platzierten Servers, nämlich der Anbindung. An dieser Stelle möchte ich Fusl danken, der mir bei dem Speedtest mit seinem Hetzner-Server, welcher in Falkenstein platziert ist, zur Seite stand. Wir haben den Durchsatz mit iperf in beide Richtungen getestet:

Auf Empfangsrichtung (vom Hetzner-Server zum vServer) erreichten wir satte 286 Mbit pro Sekunde während auf  Senderichtung (vom vServer zum Hetzner-Server) gar 618 Mbit pro Sekunde drin waren. Das liegt weit über den im Angebot ausgewiesenen 100 Mbit. [Paste]

Weiterhin habe ich einen Geschwindigkeitstest mit einem der bekannten Testfiles von der QSC AG getestet. Hierbei kam ich auf einen Durchsatz von rund 25 MB pro Sekunde, was sich mit den iperf-Ergebnissen etwa deckt. [Paste]

Ping

Zu guter Letzt komme ich zum Ping. Ich hielt das für wichtig, da dieser bei Gameservern meistens eine Rolle spielt und auf solch einem vServer ja alle möglichen Arten von Gameservern händisch installiert werden können. Von meinem aktuellen Standort aus habe ich eine durchschnittlichen Ping von 25 ms. Wenn ich wiederum mit dem vServer Fusls Hetzner-Server pinge, erreicht der Durchschnittswert 5,6 ms. [Paste]

Fazit

Die vServer von Rock-Server sind herkömmliche vServer zu einem guten Preis und eignen sich meiner Ansicht nach für das hosten einiger kleiner, nicht stark frequentierter Seiten die nicht viel Inhalt ausliefern und für kleinere Gameserver, ja sogar Minecraft-Server. Mit rund 12 Euro pro Monat bietet der Test-vServer eine gute Menge RAM, augenscheinlich fest zugewiesene CPU-Power vergleichbar mit einem etwas älteren Notebook und eine etwas kleine, aber völlig ausreichende Festplatte, die ebenfalls auf dem Niveau eines etwas älteren PC liegt und bei einigen Szenarien die Rekorde bricht, was ich für einen Fehler im Benchmarking-Tool halte. Letztlich empfiehlt es sich allerdings für Anfänger, lieber einen richtigen, fertig eingerichteten Gameserver zu nehmen, da hierbei Absicherung, Instandhaltung und Konfiguration meistens vom Anbieter übernommen wird und der Preis nur unerheblich höher ausfällt.

In nächsten Teil der Trilogie werde deshalb ich auf Gameserver von Rock-Server eingehen. Hierzu habe ich einen CS:GO-Server sowie einen Minecraft-Server für den Test vorgesehen. Auch Mods und andere Gameserver sind möglich, dazu aber dann im entsprechenden Artikel mehr. Bereits gestern habe ich die Funktionalitäten und Leistung mit mehreren Freunden ausprobiert und werde vermutlich gegen Mitte der nächsten Woche den kompletten Artikel online stellen.