vServer für einen mittleren Blog

frm

frm

Registered User
Folgende Anforderungen habe ich an einen vServer:

Debian 6 minimal
min. 1 CPU
2GB Ram
min. 50GB HD
Traffic Unlimitiert

Folgende Angebote habe ich dazu schon gefunden:
Uranus - http://www.netcup.de/bestellen/produkt.php?produkt=459
Linux Level 2 - https://www.strato-pro.com/ger/virtual-server/
vServer M - https://www.ip-projects.de/vserver-V-Server M.html

Der Blog wird mit Wordpress betrieben, Nginx soll benutzt werden.
Mehrere Tausend Besucher täglich (Herkunft DE, CH, AT).

Was könnt ihr mir empfehlen, pro und contra.
Habt ihr noch weitere Angebote für mich?
 
Je nachdem wie dein Blog aussieht und ob zB noch Mailserver auf der Plattform laufen sollen könnte 2GB RAM eng werden.
Gibt es einen spezifischen Grund warum du einen Rootserver und nicht einen entsprechend leistungsfähigen Webspace suchst?

Für anständige Webspaces sollte bei Verwendung von Caching-Plugins paar Tausend Besucher/Tag problemlos verkraftbar. Billigen/günstigen vServer wie hier verlinkt könnte aber zur Rush-hour dabei gerne mal die Puste ausgehen, zumal Nginx nicht grade der Schnellste ist wenn es um PHP-Auslieferungen geht. (Die Krone hält bei den kostenfreien Webserver Apache2 + mod_php)
Ausserdem könnte die Datenbank ebenfalls in die Knie gehen aber das ist Grösstenteils eine Sache von Caching und Optimierung.
 
Ein Mailserver wird nicht zum Einsatz kommen, dafür verwenden wir Google Apps.

Meine Idee und Planung liegt momentan bei nginx, da ich ich ein spezielles HDD Caching mit Wordpress betreiben möchte und dort nginx besonders punkten kann, da statische HTML Dateien ausgeliefert werden.

Ein Webhosting kommt für mich insoweit schon in Frage, aber es muss dort dann wirklich sehr performant sein. Mein aktueller Hoster hat leider sehr lange Zugriffszeiten, was speziell das Google Ranking beeinflussen.

Ich denke 2GB Ram für nginx und voraus erzeugte statische HTML Dateien halten eine Menge Besucher aus oder täusche ich mich da?
 
Joe User said:
Wird auf einem vServer ohnehin nicht funktionieren, da virtuelle HDDs lediglich Files im Hostsystem sind und die Syscalls entsprechend umgebogen oder gar verworfen werden.
Click to expand...

Trifft dies wirklich zu, wenn die Cache, in meinem Fall erzeugte statische HTML Seiten aufgerufen werden?
Ich benutze für den Blog Cachify.
Wenn ich hier auf meinem Test vServer das HD Caching des Plugins aktiviere und daraufhin meine Seite lade, werden die erzeugten HTML Files aber ohne Probleme geladen. Trotz vServer.
Edit: ist dies vielleicht auf die Virtualisierung zurückzuführen? Mein Testserver ist ein KVM vServer.

HD Caching ist meiner Meinung nach die einzige Variante die das hohe Besucheraufkommen aushält. APC ist zu speicherhungrig und eine DB Cache für Wordpress bringt mir ebenfalls keinen Performance Vorteil, ob ich jetzt 4 DB abfragen habe oder 10, beides kostet mich Rechenleistung. Die HD Cache hingegen kostet mich nur ein paar kb an Speicherplatz.

Korrigiert mich bitte, fals ich hiermit falsch liege!
 
Was Du meinst ist ein Opcode Cache (zumindest nehme ich das hier an, Cachify bietet ja verschiedene Optionen an). Dabei geht es darum, dass dynamische Inhalte nicht immer neu interpretiert werden müssen, sondern bereits als kompilierte, statische Dateien auf dem Server vorliegen.

Diese können dann natürlich enorm schnell und effizient ausgeliefert werden, besonders von Lighttpd und Nginx, weil das einfach perfekte Arbeitstiere für statische Dateien sind .
Und ja, das funktioniert auf vServern natürlich genauso gut.

Aber das konnte Joe zum Zeitpunkt seines Postings ja nicht wissen (das wir hier von Opcode Caches reden).
 
Statische Dokumente zu erzeugen ist kein "HDD-Caching" und auch nicht "speziell", sondern eine Technik die älter als das Internet ist.

Und ein paar tausend Visits/Tag auf statische Dokumente steckt Apache ohne viel Tuning locker weg, dafür brauchts keinen nginx.

nginx wird erst ab circa 5k Visits/Sekunde interessant, ausser man will unbedingt jedem bekloppten Hype hinterherrennen. OK, für Letzteres sollte man aktuell dann lieber node einsetzen, nginx ist schon wieder out...
 
Was Du meinst ist ein Opcode Cache
Click to expand...
Nope. Ein Opcode Cache speichert die vom PHP-Interpreter erstellte Datei welche danach in der Skriptingumgebung ausgeführt wird.
Dies spart dass er die Text-Version des PHP-Skriptes bei jedem AUfruf neu zusammenbauen und interpretieren muss (aber natürlich nicht das Kompilieren, Skriptingsprachen sind JIT-kompilierend)

Joe hat eher Linux disk-cache vermutlich gemeint. Diesen kann man zwar auf verschiedenen Hostingumgebungen nicht beeinflussen, aber sehr wohl verwenden. Solche Sachen wie Flashcache sollten aber in KVM-Virtualisierung funktionieren. Aber darum gehts hier ja nicht =)

Ein Webhosting kommt für mich insoweit schon in Frage, aber es muss dort dann wirklich sehr performant sein.
Click to expand...
Ich würde dir sehr gerne ein entsprechendes Angebot verlinken- darf ich es in eine PN fassen?
 
Vielleicht leicht OT, aber vielleicht hilfts dir bei der Planung:
Wenn du Cachify mit Festplattencaching nutzt, ist es noch sinnvoll in die RAM-Berechnung einzubeziehen, wieviel MB deine statischen Daten haben werden. Je nach Bloggröße ist das sicher zu vernachlässigen, aber bei größeren Installationen mit viel Traffic kann da ja was zusammen kommen. Wenn dein Server die dann aus dem RAM laden kann, verringert sich die Ladezeit eventuell noch mal drastisch (das war zumindest meine Erfahrung).
 
Ich kann nur empfehlen: http://www.jimwestergren.com/wordpress-with-redis-as-a-frontend-cache/

Gerade auf nem VServer!
Click to expand...

Wie gross ist denn da der Unterschied zwischen dieser Lösung und einem Wordpress internen Caching Plugin das man einfach in Wordpress installiert? Lohnt sich der Einbau denn tatsächlich? Ich habe zum Beispiel Hypercache Extended im Einsatz. Das macht ja eigentlich auch nichts anderes als html Seiten des Inhalts anzufertigen, sie auf der Festplatte zu speichern, und die dann auf Anfrage auszuliefern.
 
Last edited by a moderator:
Nein, statische Dateien sind performanter. Zumal Redis zwar _sehr_ schnell ist aber die verlinkte Implementierung des Caches auf ein PHP-Skrpt zurückgreift; bevor dieses auch nur geladen ist, hat man eine statische Datei ausgeliefert.

Wäre die Logik direkt im Webserver oder einem Application server eingebaut, käme es vermutlich recht nahe an festplattenbasiertem Cache.
 
Klar, rein statische Dateien sind immer performanter, meiner Erfahrung nach kann es bei VServern aber gern mal an der IO hängen, abhängig davon, was die Nachbarn machen.

Ein kleiner Test auf meiner Seite:

Static File:
Requests per second: 6393.04 [#/sec] (mean)

Redis Cache (phpredis module von dotdeb.org anstatt predis.php)
Requests per second: 1557.85 [#/sec] (mean)

Also ungefähr nen Faktor 4 Unterschied.

Hab mir mal eine nginx-Implementierung in Lua vorgenommen, wenn ich irgendwann mal etwas mehr Zeit hab.
 
meiner Erfahrung nach kann es bei VServern aber gern mal an der IO hängen,
Click to expand...
Bei Paravirtualisierung mit genügend Ram kannst du davon ausgehen dass alle relevanten Dateien ziemlich fix im Disk Cache liegen und die Festplatte (von dir) unbelastet ist. Isolierung (Openvz) kannst du nicht davon ausgehen aber der Cache des Hosts sollte bei mässigen Besucherzahlen trotzdem die Datei schnell zwischengespeichert haben.

Hab mir mal eine nginx-Implementierung in Lua vorgenommen, wenn ich irgendwann mal etwas mehr Zeit hab.
Click to expand...
Was spricht gegen direktes Cachen in Varnish? Optimaler sollte es nicht mehr gehen und mittels TCP-Interface kann man einzelne Dateien oder ganze Url's aus dem Cache werfen.
Respektiv alternativ; warum überhaupt eine Datenbankengine wie Redis, wäre Memcache(d) nicht der sinnvollere Weg wenn man cachen will?
 
Einverstanden mit der IO :-)

Naja, ich hab nginx am laufen und der könnte auch cachen, wenn man ihm das beibringt. Ein proxy vor einem proxy macht da nicht allzu viel Sinn für mich.

Ich benutze Redis mittlerweile zum cachen von allem möglichen, weils
a) meist einfach einzubinden ist
b) sich Performance-mäßig zu memcached nicht viel nimmt
c) man außer get, set, delete noch viele weitere Befehle und Datentypen hat und man nicht nur auf Key-Value Angelegenheiten beschränkt ist.
d) man Redis auch persistent betreiben kann.
 
You must log in or register to reply here.
Back
Top