Artikelformat

Grenzerfahrungen: WP Cacheplugins, Apacheoptimierung oder doch neue Hardware?

Bild 640.jpg

In der letzten Woche konnte ich sehr gut beobachten, wie meine derzeitige Blogserver-Konfiguration auch bei grösseren Zugriffszahlen skaliert. Das Interesse an der Keynote und auch an der Windows 7 Beta waren sehr gross. Und es war ehrlich gesagt eine Katastrophe. Sollten sich die Zugriffszahlen weiterhin positiv entwickeln, muss ich wohl meinen virtuellen Server aufgeben und lieber auf richtige Hardware setzen. Auch der Einsatz von Cache-Plugins und einigen Optimierungen am Apacheserver sind angedacht. Es wird wohl eine Mischung aus allem.

Eventuell hat aber auch jemand speziellere Erfahrungen auf diesen Gebiet und kann mir ein paar Tipps geben. Ich habe dafür derzeit ein besonders grosses Ohr offen.

Links

Autor: Oliver

Ich bin Oliver und habe den aptgetupdateDE Blog im Juli 2007 aus der Taufe gehoben. Man findet mich auch auf Twitter.

15 Kommentare

  1. Mh, ich weis zwar nicht wie hoch deine Spitzen in in Zahlen sind. Aber ich kann dir empfehlen auf einen „echten“ Server umzusteigen. Und sei es nur ein „Power Server“ von Strato für 44 Euro mit 1 GB Ram.

    Den Einsatz von eAccelerator o.ä. könnte ich auch empfehlen.

    Oft bremsen auch div. WP Plugins das System aus. Dort gilt es einfach mal zu testen.

  2. Was Cache-Plugins für WordPress angeht, so habe ich an diversen Stellen bereits gelesen, dass sie die Leistung eines vServers eher noch stärker beanspruchen. Selber habe ich es nicht getestet, wobei ich es für durchaus plausibel halte. Ich würde definitiv ein Hardwareupgrade vor Optimierungsmaßnahmen bevorzugen. Keine auch so gute Optimierung kann bessere Hardware ersetzen.

  3. Ohne genauere Informationen ueber das jetzige System (Server & Software) kann man natuerlich kaum etwas empfehlen, wenn man nicht weiss, wo die Schwachpunkte liegen. Ist es CPU-maessig am Anschlag durch die Generierung von Seiten oder schlurfelt die DB herum? Oder ist I/O generell ein Problem und es kommt zu einem hohen wait i/o?

    Natuerlich sind virtuelle Server da meistens etwas schlechter, weil andere VMs sowohl die CPU als auch die Disk I/O beanspruchen.

    Ich nehme mal an, dass als DB MySQL verwendet wird, so dass man da auch noch etwas verbessern kann. MySQL empfiehlt und installiert z.B. laut Kris Koehntopp seit laengerer Zeit XFS als Filesystem fuer die DB.
    Vermutlich laesst sich die Last aber auch durch sowas wie memcached oder andere Loesungen senken.

    Ansonsten koennen wir da ja auch mal auf dem OpenLab demnaechst drueber reden. Passt ja zum Thema irgendwie… ;-)

  4. Hallo,

    Wichtig ist noch die Ausgabe von /proc/user_beancounters die dir bei einem OpenVZ System die Probleme schwarz auf weiss dokumentieren. Speicherprobleme CPU Zeit überschreitungen der gleichen.

    Wenn deine Maschine auf einem XEN oder Vm-Ware System rattert dann weiß ich leider spontan nicht wie du zu einer ähnlichen Übersicht gelangst.

    Anschließend würde ich beginnen mit dem Ausmisten und der Optimierung der Serverdienste.

    Alle ungenutzten Module aus dem Apache raus.
    Cache Werte von MySQL anpassen.
    PHP Xcache extension installieren. etc.

    GZip komprimierung des Webservers aktivieren oder direkt über den gz_handler von PHP.

    Ich stand darmals vor einem ähnlichen Problem. Habe mich aber nach den Optimierungen dazu entschlossen auf einen Rootserver zu wechseln.

    Ich hatte mich für Hetzner entschieden, allein aufgrund der Vertragslaufzeit von einem Monat.

    Den Hohen Preis des DS 9000 hatte ich mir mit zwei meiner Arbeiskollegen geteilt, somit ist jeder bei erträglichen 33 Euro im Monat.

    Das Grundsystem ist auf XEN Basis und die Ressourcen gereicht durch 3 geteilt.

    Viele Grüße

  5. @Ingo Juergensmann: gute Idee, dass können wir sehr gerne machen

    CPU Last ist ok, ich würde auch eher die Probleme im I/O sehen. Besonders bei vielen Netzwerkverbindungen bricht die Perfomance sehr stark ein.

    @127.0.0.1: mal sehen was ich ausgeben kann

    xenserver:~ # xm list
    Name ID Mem VCPUs State Time(s)
    Domain-0 0 512 4 r—– 84936.4
    aptgetupdate 11 1524 1 r—– 87911.5

    xentop – 10:41:19 Xen 3.1.0
    6 domains: 1 running, 5 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown
    Mem: 4192216k total, 2590848k used, 1601368k free CPUs: 4 @ 2000MHz
    NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR SSID
    aptgetupdate –b— 87968 3.2 1560576 37.2 1560576 37.2 1 1 586886 1643881 2 0 147711 2004325 0

    Aber es gibt bestimmt noch diverse Tools zu Analyse.

  6. @Oliver Friedrich: Wie schaut das denn mit den anderen 4-5 VMs aus? Laeuft die aptgetupdate VM mit 1 CPU oder mit mehreren? Swappen die anderen VMs oder tut es aptgetupdate? Hilft mehr RAM?
    Wie schaut das Platten-Setup aus? Nur eine Platte, ein RAID?

  7. Ich glaube nicht, dass es an den Zugriffszahlen liegt. aptgetupdate war noch nie besonders schnell. Ich hatte früher Apfelquak und admartinator.de auf einer Datenbank liegen – und das in Zeiten, wo ich massenhaft Zugriffe hatte. Selbst das war schneller.

    Wieviel Hits waren denn das da oben?

  8. @ad: da magst du auch recht haben, das Problem an diesen Tagen war die konzentration der Zugriffe auf wenige Stunden (ca. 300 Leute pro 5 min)

    @Ingo Juergensmann: ich fahre da eine interessante Installation mit mehrern Xen Servern, die gemeinsam auf Shared Storage zugreifen. Dieses wird per ATA over Ethernet angesteuert, ähnlich wie iSCSI über ein dezitiertes StorageNetz. Hier sehe ich vorallem den Engpass.

    Natürlich ist es schwer ohne genaue Kenntnis der Installation, genaue Tipps ab zu geben. Hier wurden aber schon diverse Stichwörter genannt, dir mir schon mal weiterhelfen. Danke dafür.

  9. @Oliver Friedrich: Oeh, nur mal so interessehalber: beim Storagenetzwerk hast Du aber auch Jumbo-Frames benutzt?
    Sonst wundert es mich nicht, dass das bei mehr Last in die Knie geht.
    Wobei Jumbo-Frames auch kein Allheilmittel sind bei Ethernet….

    Du kannst ja mal dein Setup beim OpenLab vorstellen… ;)

  10. @Ingo Juergensmann: ah guter Ansatz, nein da habe ich nichts in dieser Hinsicht konfigriert – muss ich erst mal schaun, ob das mein Switch auch unterstützt (ist nämlich nur ein Netgear). Muss man dann auch die Netzwerkkarten der Server anpassen bzw. konfigurieren? Oder reicht die Einstellung am Switch?

  11. Ich kann dir sagen, was du noch machen kannst, ich mache bei jeder entwickelten Seite wo es möglich ist das gleiche:

    Vorher aber:
    Erstmal Firebug und YSlow installieren, zwei Super FF Extensions zum Analysieren der Webseite.

    Dann gehts los:
    HTTP-Requests vermindern. Du bindest 11 Stylesheet- und 20 JS-Dateien ein. Die kann man alle zusammenfassen und komprimieren. Du hast 11 CSS Images, die kann man als Sprite zusammenfassen womöglich.

    Du benutzt Apache. Evtl ist Lighttp besser. Zumindest für statische Daten. Einfach mal testen

    Nutzt Apache bei dir gzip komprimierung? So wie es aussieht nicht. Das hat bei mir erheblich Bandbreite gespaart.

    Nutzt du EAccelerator o.ä.? Ausprobieren!

    YSlow zeigt mir, dass bei jedem Seitenaufruf 580kb Daten gezogen werden, davon sind 320kb nur JS Files, die kann man komprimieren könnte. Die sind danach nur noch einen Bruchteil so groß. Und wie oben schon beschrieben sollte man nur eine CSS und eine JS Datei einbinden.

    Die Bilder könnten noch optimiert werden. Alleine die Datei im Kopf der Seite kann stärker komprimiert werden. Die Simpsonsfiguren und der Text könnten als einzelne Bilder eingespeist werden, so dass man den Rest stark komprimieren kann. Da lassen sich auch noch mal 15-20kb rausholen.

    So. Das macht 53 Euro. Alternativ ein Platz in der Blogroll :-p

    Edit: Ich seh grad, dass du viele verschiedene JScript Frameworks einbindest. Prototype, JQuery, Scriptalous. Da könnte eines reichen, die machen doch eh alle das gleiche

  12. Ich selsbst nutze einen RootServer von Server4You (~40€ im Monat). DualCore CPU 2×2 GhZ und 1GB Ram.

    Ich betreibe ein US-Funblog auf diesem Server. Ohne WP-Supercache ist das Ding allerdings schon bei ca 30k uniques pro Tag in die Knie gegangen. Mit WP-Supercache sind auch 150k uniques kein Problem mehr :-)