Blog

vServer und Performance (2)

Wie kann man denn nun mit einfachsten Mitteln die Leistung von vServern vergleichen? Ich habe mich da nur wenig mit befasst, aber interessant differierende Werte findet man schnell mit dem guten alten

hdparm -t /dev/sd(a).

Während das bei dem einen Hoster Werte von knapp 200 MB/s ergibt (das landet offenbar im RAM oder einem SSD-Cache), findet man beim unten besprochenen Hoster einen Plattendurchsatz von 30 MB/s, und das stark schwankend. Das ist manchmal so wenig, dass sogar vi bei großen Dateien ruckelt.

Wenn es um Webhosting geht, gibt es ein simples Tool, mit dem man den wichtigsten Benchmark sehr einfach durchführen kann: Wie schnell werden Seiten ausgeliefert?

Das geht mit httping:

httping -G -B -c 50 -A -U username -P password hostname.net

Obiger Befehl führt ein GET auf hostname.net aus und misst über 50 Requests die durchschnittliche Antwortzeit und den Durchsatz. Dadurch, dass mit -B Kompression aktiviert wird, spielt die Leistung der CPU des vServers eine gewisse Rolle. Mit -A -U -B kann man auch .htaccess-geschützte Seiten testen, sodass das Tool auch im Prototypen-Stadium einer Web-Anwendung eingesetzt werden kann.

vServer und Performance

Server

In der letzten Zeit habe ich mich bei einigen Hostern, bzw. bei den jeweiligen vServer-Produkten umgesehen. Neben harten Fakten wie Preis und garantiertem RAM mangelt es in diesem Bereich leider an objektiv vergleichbaren Parametern: Einen standardisierten Benchmark hierfür gibt es nicht und selbst wenn, wüsste man nicht, ob die Ergebnisse auf das eingene Nutzungsprofil übertragbar wären.

So bleibt einem nur das Ausprobieren. Und da findet man schnell heraus, dass die Setups der Provider offenbar noch lange nicht so ausgereift sind, wie die Marketing-Tools.

Bei einem Hoster – übrigens einem mit gutem Ruf – habe ich einen kleinen Debian-vServer laufen, der durchaus bemerkenswerte Ecken und Kanten hat. So blieb die Instanz innerhalb der ersten drei Wochen gleich dreimal einfach stehen. Ein Verhalten, dass man von Debian so nicht erwartet. Im Log fanden sich seltsame Fehlermeldungen, die auf einen bekannten Timer-Bug hinwiesen, der im Zusammenhang mit vServern gelegentlich auftritt. Da habe ich natürlich erstmal recherchiert und Workarounds getestet.

Als ich beim dritten Crash und einem nicht wiederzubelebenden Server den Support kontaktierte, stellte sich heraus, dass gar nicht das Debian schuld war, sondern dass dem Hostsystem offenbar regelmäßig (?) das Filesystem abhanden kommt. Wen wundert es, dass die Guests seltsames Verhalten zeigen?

Hinzu kommt, dass das Hostsystem gefühlt massiv von Gamern genutzt wird. Während die Performance tagsüber ausreichend ist, fängt es abends an zu haken und man merkt, dass die Maschine an ihre Grenzen stößt. Ein CMS ist so nur schlecht zu bedienen.

Das einzig Gute dort war der Support, der jederzeit im Chat zur Seite stand. Aber das Setup ist noch im Beta-Stadium und für professionelle Nutzung definitiv ungeeignet. Wer die Erfahrungen nicht selbst machen will, kann mich gerne nach dem Hoster-Namen fragen.

Fortsetzung: Digitales Debakel

Der Herr Comodohacker alias Ichsun behauptet, dass er GlobalSign und noch drei weitere CAs gehackt hat (Zitat). Wenn das stimmt, ist das möglicherweise der Anfang vom Ende von aktuell genutzten PKI-Strukturen. Das betrifft dann Homebanking genauso wie jede Menge elektronische Geschäftsanwendungen und staatliche Projekte.

Klassischer “Single Point of Failure”.

Ich hätte zudem erwartet, dass eine CA wie DigiNotar seine Systeme besser sichert, als das der Fall war. Die Zertifikate lagen wohl auf ungepatchten Windows-Systemen ohne Virenschutz, die Domäne war mit bruteforcebarem Passwort gesichert. Zudem konnte Herr Comodohacker anschließend die Logfiles löschen, wie es eben Hackertradition ist. Jetzt weiß man hat nicht so ganz genau, was er alles getrieben hat. Irgendwie kann ich kaum glauben, dass das alles wahr ist.

Digitales Debakel

Dank des DigiNotar-Debakels fällt nun so manchem auf, dass SSL/TLS am seidenen Faden einiger recht willkürlich gewählter CAs hängt. *Irgendjemand* war offenbar in der Lage, sich selbst für Domains u.a. von Twitter, Google, Mossad, CIA, MI6 aber auch so netten Dingen wie windowsupdate.com zu erstellen. Letzteres ist besonders delikat, wenn man das Codesigning noch hinbekommt.

*Irgendjemand* kann damit nun, sofern er einen MITM-Angriff schafft, den DNS oder die host-Liste manipuliert, die von/zu den in dieser Liste genannten Domains vermeintlich sicher übertragenen Daten mitlesen oder verändern.

CAs sind ein Single Point of Failure der Internetsicherheit. Und Browser vertrauen diesen CAs recht blind. Es ist höchste Zeit, über strukturelle Änderungen in diesem Bereich nachzudenken.

Philosophie der Preise

Heute aufgeschnappt. Situation: Diskussion um Preise von Tablets und Laptops:

Es gibt kaum etwas auf dieser Welt, das nicht irgend jemand ein wenig schlechter machen und etwas billiger verkaufen könnte, und die Menschen, die sich nur am Preis orientieren, werden die gerechte Beute solcher Machenschaften.

Es ist unklug, zu viel zu bezahlen, aber es ist noch schlechter, zu wenig zu bezahlen.

Wenn Sie zu viel bezahlen, verlieren Sie etwas Geld. Das ist alles. Wenn Sie dagegen zu wenig bezahlen, verlieren Sie manchmal alles, da der gekaufte Gegenstand die ihm zugedachte Aufgabe nicht erfüllen kann.

Das Gesetz der Wirtschaft verbietet es, für wenig Geld viel Wert zu erhalten. Nehmen Sie das niedrigste Angebot an, müssen Sie für das Risiko, das Sie eingehen, etwas hinzurechnen. Und wenn Sie das tun, dann haben Sie auch genug Geld, um für etwas Besseres zu bezahlen.

Zugeschrieben John Ruskin (1819-1900)

Schön gesagt, Ruskin.

© Copyright schulten.net