Kurzzeitig offline

Heute war das Design Tagebuch einmal etwas länger offline. Die Zugriffe auf die Datenbank überstieg die Kapazität des Servers. Gegen 16.00 Uhr waren erstmalig mehr als 100 Nutzer zeitgleich online.

Allinkl.com hat mir mitgeteilt, das sie den Auftritt erst einmal auf einen eigenen Server legen wollen, um dort ein Monitoring laufen zu lassen. Jetzt gibt es zwei Alternativen: a) die Datenbankabfragen lassen sich soweit optimieren, dass der Server nicht mehr in die Knie geht und der Auftritt auf dem SharedServer gemeinsam mit 24 anderen Präsenzen liegen bleiben kann oder b) das dt zieht auf einen eigenen Server um.

Ich habe vorsorglich einmal das Statistik-Plugin Semmlstaz deaktiviert, von dem ich weiß, dass es immer umfangreiche Tabellen anlegt. Würde mich sehr über Tipps freuen, wie sich die Datenbankzugriffe weiter optimieren lassen.

35 Kommentare zu “Kurzzeitig offline

  1. guck dir doch mal Drupal (www.drupal.org) an.

    Das kann mindestens genausoviel wie WordPress, Joomla und wie sie nicht alle heißen und hat zusätzlich noch von Haus aus nen gutes Caching, plus ne klasse Integration von Memcache.

    An Allinkl.com kann das gar nicht liegen.. die sind schließlich mein Lieblingsprovider :)

  2. Also soweit ich weiß wird es in Version 2.6 wieder viele Verbesserungen geben.

    Aber da dein Blog schon lange existiert könnte ich mir gut vorstellen das du viele Plug-ins drinne hast die vllt. garnicht mehr sein müssen weil es WordPress mitlerweile mitbringt.

    Warum nutzt du eig. Semmelstats?
    Also ich habe das WordPress Stats Plug-In am laufen und bin damit voll zufrieden, außerdem läßt es meine db in ruhe!

    Den Rest kann ich via Logfiles auf dem Server auslesen.

    Also Tipp von mir:
    Einfach mal durch dein wp gehen und schauen was weg kann und was bleiben muss weil es wp sonst nicht kann.

  3. @Sven

    Warum kann man die Kommentare nicht aus einem Cache holen? Das ist schlicht falsch. Man braucht nur einen dynamischen Cache, der keine fixe Lebenszeit hat, sondern bei jedem schreibenden Request neu gebaut wird. Der Kommentarcache pro Artikel lebt dann beispielsweise zwischen wenigen Sekunden (ggf. neuester Artikel) und vielen Monaten (älterer Artikel). Idealerweise werden nicht nur die Datenbankwerte in einen Cache gepackt, sondern der ganze fertige HTML-Bereich (View-Caching). Ich kenne WordPress nicht, aber jedes vernünftige Framework kann das.

    Insgesamt lässt WP je nach PlugIns und Statistikfunktionen vermutlich irgendetwas zwischen 10 und 100 SQL-Statements pro generierter HTML-Seite auf den Datenbankserver los. Mit schlauem Caching kann man das vermutlich auf ein Zehntel reduzieren. Insbesondere die ganzen Punkte rechts im Menü (Heiß diskutiert, Gewinnspiele, Trend, Empfehlungen, Interessant, usw.) setzen vermutlich alle mindestens 1 SQL-Statement ab und sind ideal für einen Cache.

  4. @Guido
    Selbstverständlich kann man alles Cachen. Ich bezweifle aber, dass es so ein ausgereiftes Caching System gibt, deshalb bin ich mal von der „normalsten“ Caching-Methode ausgegangen. Aber du hast natürlich recht, da stimmt meine Formulierung nicht ganz.

    Was ich allerdings nicht dachte ist, dass WordPress doch so viele Ressourcen braucht. Bevor ich nun meinen privaten Blog mit Einträgen voll mache, sollte ich vielleicht nochmal genauer hinter die Kulissen schauen…

  5. Noch ne Idee: Lagere deinen Feed zu Feedburner aus. Dein Feed wird aktuell direkt von deinem Shared-Account generiert, was natürlich auch ne dicke Last bedeutet… denn so ein Feed hat teilweise echt Hochkonjunktur und wird oft sogar öfter abgegriffen als die Seite selber.

    Also schleunigst den Feed zu Feedburner umziehen, der greift den Feed dann nur noch ab wenn er sich ändert bzw. alle 30 Minuten zu Kontrolle und du solltest schon ein ganzes Stück an Last verlieren.

    Und nochmal zu WordPress: Ich habe in letzter Zeit WordPress-Seiten gesehen die zwischen 4 und 8 Sekunden zum parsen benötigt haben, und das auf ganz normalen Hostingsystemen. Das waren keine Einzelfälle sondern schon fast die Norm. Solche Zeiten sind einfach nicht vertretbar… alles was über 0.5 Sekunden liegt ist schon derbe schlecht, was über einer Sekunde ist einfach Müll.

    Ein Grund mehr warum ich nicht verstehe warum jeder wie bekloppt diese Fricklware benutzt.

  6. Also, zuerst mal: Hoster ist okay, WordPress ist auch okay – es ist nun mal so, und sich hier Gedanken zu machen, das ganze BlogSystem auf eine andere Platform zu migrieren scheitert alleine am unverhältnismäßigen Aufwand.

    Einige Tipps sind schon gut: WP auf unnütze PlugIns durchsehen – ggf. die TemplateFiles optimieren. WPCache ist eine brauchbare Cachinglösung, bedarf aber ein wenig KnowHow.

    Man kann aber leider nicht verallgemeinern, dass ein Cache unbedingt die DB-Last verringert. Aber mit ordentlicher Optimierung ist das durchaus ein realistisches Ziel.

    Das neue WP (2.5.1) wie du es im Einsatz hast, ist sicher noch Performance-Verbesserungsfähig, aber trotz allem keine schlechte Sache. Wir betreiben Sharebrain.info mit WP 2.5.1 und haben da auch reichlich Traffic, trotzdem ist die Last auf dem Server okay. Auch hier kommt WPCache zum Einsatz. Wenn du Fragen hast oder Hilfe brauchst, meld dich einfach!

    Viele Grüße
    Rico

    PS: Dass der Hoster in Ordnung ist, siehst du alleine daran, dass sie sich Gedanken um die Präsenz machen und sie testweise auf ein Monitoringsystem packen wollen.

  7. Ein kleiner Tipp: Jeder von hier kennt sicherlich den BildBLOG und dieser hat ebenfalls mit Sicherheit immens hohe Zugriffszahlen, läuft aber recht flott, wenn man die Seite ansurft, basiert aber auch auf WordPress. Vielleicht solltest du einfach mal die Kollegen anschreiben und mal nachfragen, wie die das optimiert haben? ;)

  8. Ncoh schnell, weil ich es grad wieder gefunden habe:
    http://bueltge.de/wordpress-performance-analysieren-plugin/558/

    Dieses Plugin protokolliert übersichtliche alle angefallen SQL-Queries. „Nach dem Aktivieren des Plugins werden die einzelnen Abfragen in den Footer der Seite geschrieben, als HTML-Kommentar, so dass man den Quelltext analysieren muss, um an die Werte zu kommen. Die Werte werden nur analysiert und ausgegeben, wenn man als Administrator im Blog eingeloggt ist.“

    Sehr praktisch!

    Viele Grüße
    Rico

  9. ich würde auch cashing bevorzugen. das angesprochenen parcing problem kann auch auch ein problem des hosters sein. ich habe eine news seite mit durchschnittlich 1000 unique besucher pro tag. bei meinem alten hoster war parcing kein problem, seit ich zu einem amerikanischen hoster gewechselt habe, braucht es jedesmal über 2 sekunden.

    bei datenbank abfragen würde ich als erstes alle plugins deaktivieren, die nicht lebensnotwendig sind. eine Cashing system ist auch zu empfehlen, wobei WP cache nicht grad der beste plugin ist.

    hier der supercashe:
    http://ocaoimh.ie/wp-super-cache/

    und wie man ihn noch schneller macht:
    http://www.askapache.com/wordpress/wp-cache-speed-hack.html

    viel erfolg

Pingbacks

Kommentar verfassen

Folgende HTML-Elemente können verwendet werden: <b> <i> <img src="meineurl"> <a> <blockquote>