Wie sicher einige mitbekommen haben, war mein Blog, genauer gesagt meine Datenbank, heute mal wieder abgeschaltet.
Ich bekam von DomainFactory auch wieder eine eMail, mit dem selben Wortlaut wie gestern. Das ist ja auch Okay, da diese Abschaltung mit Sicherheit automatisch passiert, wenn bestimmte Grenzwerte überschritten werden. Es handelt sich also um eine automatische Mail.
Eine Minute später bekam ich noch eine weitere eMail, in der ein Serverumzug angekündigt wurde, um die Lastprobleme zu beheben.
Das finde ich ja erstmal einen netten Zug. Anscheinend schließt DF nicht mehr gänzlich aus, dass das Problem auch dort liegen könnte.
Insgesamt sehe ich die Reaktion seitens DF recht positiv. Denn aus Sicht von DF müssen sie natürlich die Stabilität des gesamten Systems gewährleisten. Und es gibt sicher oft genug Websites, die Chats oder andere lastintensive Skripte einsetzen und damit die Datenbank zum Rauchen bringen.
Cache
Ich habe mich heute mit WP Super Cache herum geschlagen. Allerdings wollte dieses Caching Plugin nicht so wie ich wollte.
Also habe ich mich nach einer Alternative umgeschaut. Da bin ich auf Hypercache gestoßen. Die Installation verlief reibungslos und die Seiten werden nun gecached. Wenn ein neuer Post kommt oder Kommentare hinterlassen werden, dann wird der Cache natürlich geupdated.
Bemerken kann man den Cache vor allem an der Anzeige der “User online” ganz oben im Blog. Da könnte es zu sehr unterschiedlichen Anzeigen kommen. Ich werde das Plugin wahrscheinlich in den nächsten Tagen ausbauen.
Frühjahrsputz
Gestern habe ich zudem mein Blog etwas entschlackt. Ich habe 2 Plugins deaktiviert. Diese Plugins haben jeweils recht viele Datenbank-Queries verursacht. Insgesamt konnte ich so rund 50 Datenbank-Abfragen einsparen.
Die entfernten Plugins sind “Show Top Commentators” und “Multi Column Category List”.
Nun habe ich “nur” noch 60-70 DB-Queries pro Seitenaufruf. Und durch den Cache werden diese ja auch teilweise nicht mehr verursacht.
Bangen und Hoffen
Ich hoffe, dass die Maßnahmen meinerseits und der Serverumzug durch DF das Problem lösen und hier alles wieder seinen gewohnten Gang gehen kann.
Wir werden sehen.
Morgen gibt es, wenn alles normal läuft, wieder neue Artikel.
Hier findest Du weitere Informationen zu diesem Thema:
Mein Name ist Peer Wandiger und ich bin selbständiger Webdesigner, Programmierer und Blogger.
Loading ...
Über mich
Folge mir auf Twitter
Ich bei Google+
Die besten Artikel
Wir hatten bei 1und1 dasselbe Problem. Scheint wohl die Hoster mit Zunahme von Blogs alle einheitlich zu treffen. Unsere Lösung war der Umzug auf einen eigenen Server – zwar teurer aber dafür stimmt jetzt die Geschwindigkeit.
Gruss, V.Hepp
Hallo,
also bei mir hat WP Super Cache auch nicht funktioniert. Bin daher ebenfalls zu Hyper Cache gewechselt. Allerdings habe ich beim Traffic keinen Unterschied feststellen können. auch die Anzahl der Datenbankzugriffe blkieb gleich.
Bin gespannt, wie es bei dir aussieht.
Paul
Wollte dir schon ne E-Mail bezüglich deiner Plugins schreiben, nun mache das eben als Kommentar auf diesem Weg. Kann man irgendwo in deinem Blog anschauen was du für Plugin’s alles nutzt, gibt es so eine Ãœbersichtsseite? Wäre nämlich durchaus mal interessant zu wissen, was ein Erfolgreicher Blogger so nutzt an kleinen Helferchen im Hintergrund.
Zum Thema Datenbanken und entschlacken kann ich nur sagen, das man sowas mehrmals pro Jahr machen sollte. Alle 2-3 Monate schaue ich zum Beispiel bei meinem Blog was man optimieren könnte an der DB und wo evtl. sich wieder eine Datenbankleiche gebildet hat o.ä !
Ansonsten wenn das mit dem Hoster nicht mehr passt, einfach Hoster wechseln und gut ist.
Deine Bemühungen sind ja gut gemeint, aber ein normales WordPress-Blog darf doch selbst bei einem Shared Hosting keine Datenbank-Überlast produzieren.
Tja offensichtlich doch.
Ist ja schon mal gut. .. Hätten wir die DF-Beratung bezgl. “Support” nun auch geklärt … “Grins”.
@Ana:
Ohh doch, galub mir. Gerade Software wie WP oder Joomla bei denen duzende Fremd -Hobby- Authoren Plugins schreiben können eine Datenbank so richtig belasten. Ich arbeite seit 12 Jahren in der IT Branche und hab so einiges erlebt, die meisten Probleme kommen dabei von Usern die entweder a) selbst Programmierte Seiten betreiben oder b) fertige Systeme mit duzenden Plugins nutzen. Das Problem ist das WordPress keine einheitliche Datenbank Cache Struktur verwendet jedes Plugin kocht also in der Sache Kommunikation mit der Datenbank sein eigenes süppchen. Nun sind gerade SQL Querys sehr Optimierungs nötig wenn man da nur mit halbwissen rangeht kann das schnell viel RAM auf dem Server verschlingen.
@Peer: Ich drücke dir mal die Daumen das die Probleme, ich empfehle dir mal das Plugin “DB Cache” von Dmitry Svarytsevych anzusehen. Entgegen WP Supercache werden hier nicht die Ausgabeseiten gecached sondern direkt die Datenbankquerys (die meistens das Problem sind)
Scheint zu funktionieren.
Requests per second: 54.95 [#/sec] (mean)
Time per request: 181.999 [ms] (mean)
Time per request: 18.200 [ms] (mean, across all concurrent requests)
@Marco: die Datenbankzugriffe sind bei WordPress das geringste Ãœbel. Die dauern nur einige wenige Millisekunden. Das Problem sind Megabytes an PHP, die bei jedem Seitenaufruf geladen, geparst und natürlich auch ausgeführt werden müssen. Durch Caches, kann man das verhindern und spart sehr viel mehr Zeit als jeder Mysql Cache oder Optimierung der sowieso schon fixen Queries …
wechsel zu all-inkl, da ist das kein prob!
Hallo, ich verfolge deinen Blog erst seit kurzem. Super Informationen! 60-70 DB Queries pro Seite kommen mir extrem viel vor. Ich selbst betreibe eine Community mit Forum. Hab grad nachgeschaut: Die wichtigsten Seiten meines vBulletin-Forums (Start, Threadlist, Thread) benötigen zwischen 11 und 16 Queries pro Seite. vBulletin cached aber auch schön brav. Ein paar kommen allerdings noch durch phpAdsNew hinzu.
Interessant wäre auch, ob DomainFactory den mySQL Query Cache aktiviert hat. Grad bei Seiten, wo hauptsächlich gelesen wird, würde sich das sicher sehr auszahlen. Und bei den aktuellen Speichergrößen haben da einige Queries Platz.
Meine Seite ist ca. 10 Jahre alt. Shared Hosting habe ich mir allerdings nur 2 oder 3 Jahre angetan. Später einen eigenen Server zu Viert. Seit 6 Jahren einen eigenen Server. Finanziert durch Webhosting an Freunde und Bekannte für ihre kleinen Seiten. Läuft sehr stabil, außer man ist so blöd wie ich letztes Wochenende: Freitag Abend, Skihütte weitab jeglicher Zivilsation, drittes Bier, Anruf: Das Forum steht! März ist gut gelaufen und die eingestellte Traffic-Grenze wurde übrerschritten. Außerdem hatte ich bei diesem Account keine Kontakt-E-Mail für Warnungen eingetragen…
Joost von yoast.com optimiert übrigens auch gerade seine Datenbankqueries und publiziert hier einige nützliche Erkentnisse: http://yoast.com/wordpress-performance-optimization
Vielleicht ist was für Dich dabei, Peer.
@Sebbi: Im Fall von Peer war es glaub ich nur die Datenbank die abgeschalten wurde daher ist die memsize von PHP eher zu vernachlässigen. Jenachdem wie ein Plugin geschrieben ist kann es auf dem SQL Server ein vielfaches von dem Verbrauchen was ein PHP script benötigt. Als Beispiel nehme ich immer Statistik Plugins die jeden Seitenbesucher loggen und damit Gigantische Datenbanken entstehen lassen.
Hier mal eine Statistik eines durchschnittlich genutztem SQL Systems, wenn du dir nun vorstellst das eine Query die nicht korrekt mit Keys arbeitet mal bis zu 8MB brauchen kann… gute Nacht
Insgesamt ø pro Stunde ø pro Minute ø pro Sekunde
11 M 120,18 k 2,00 k 33,38
Die Bandbreite scheint nicht das Problem zu sein, sondern die vielen DB-Zugriffe. Da bin ich allerdings nicht so wirklich Spezialist.
Wie auch immer, Hypercache scheint gut zu laufen. Hoffen wir mal, dass bleibt so.
@ Internetagentur Berlin
Danke für den Link. Ich schaue es mir mal an.
@ noox
Naja, WordPress selbst hat schon irgendwas zwischen 20 und 30 Queries. Und zudem habe ich viele Plugins installiert. Nur auf wenige will ich verzichten. Schließlich machen erst die vielen Plugins WordPress zu dem was es ist.
Naja .. ich tippe auch auf die “Queries”. Da die unterschiedlichen Hoster, weiss nicht wie es bei DF ist, die ganze “Serverausfallsicherheit” ja gewährlisten müssen. daher gibt es da so “limits” … wie stark ein Hosting Paket genutzt werden kann, zumindest stellen eingie Hoster dies so ein.. und dann kann es eben zum Ausfall eines “Pakestes” in dem Fall, Deinem,. kommen, damit der ganze Server, also alle anderen “Mithoster” wenigsten “Online bleibeN” , und dass mit vernünftiger “Leistung”.
Gab vorhin den Serverumzug – mal sehen wie’s jetzt läuft.
Also bei mir sind’s 16 Queries auf der Startseite. Naja mein Blog ist noch neu, hab allerdings auch so ca. 20 PlugIns installiert.
Jetzt hau ich mich aber mal wieder hin.. spät genug
Ich habe mal eine Frage, trifft zwar nicht ganz das Thema aber bräuchte dringend Hilfe. Habe für meine Freundin einen Blog über WordPress laufen und wollte mal wissen wie man den Spam einfach bekämpft ohne 5 Plugins installieren zu müssen. Sie bekommt im Schnitt 10-50 Spam Kommentare pro Tag, die ist nicht so schön und den Blog gibt es noch gar nicht so lange. Habe schon mal gegoogelt aber auch nichts richtiges gefunden um das Problem zu beheben. Vielen Dank für eine Antwort, gern auch per Mail.
DF hat in den letzten Tagen so einige Seiten / Programme abgeschaltet wegen angeblicher Serverüberlastung. Anscheinend, so zumindestens meine Erfahrung, sind hohe Besucherzahlen bei statischen Seiten kein Problem, sobald man jedoch Datenbanken nutzt sind die Prozesse bzw. Lasten zu gering ausgelegt, so dass gerne mal abgeschaltet wird, anstatt die Probleme auf andere Weise zu lösen.
Aber ich stimme Tobias zu : Ab einer gewissen Größe ist es sicher ratsam einen eigenen Server zu mieten und somit auch die Verantwortung für die eingesetzten Prozesserzeuger zu übernehmen.
Wenn der Server zusammenbricht möchte ich selber dafür verantwortlich sein und nicht zwangsabgeschaltet werden um dann mühsam den Fehler zu finden.
@ Frank
Ich setze Akismet ein. Damit bin ich sehr zufrieden. Es landen so gut wie keine SPAM-Kommentare im Blog. Allerdings landen doch einige im Freischaltordner von Akismet, die man dann aber einfach löschen kann.
@ Sven
Aber nicht jeder will sich mit den Details eines Servers herumschlagen.
Ich habe eh schon genug zu tun und möchte bestimmte Dinge einfach nicht selber machen.
Mich würde interessieren wie du die Querys gemessen hast. Also nur ein Richtwert wäre nötig.
Ich glaube auch das WordPress plus Plugins sehr die Datenbank belastet. Ist ja auch logisch, bei 10 Aufrufen gleichzeitig wären das bei Peer dann vielleicht 700 Anfragen in einer oder wenigen Sekunde(n). Und dann noch die anderen Websites auf dem Server…
Das Verhalten von DF finde ich gut, andere Sperren auch gern Mal.
Hmmm, hast du ein Statistikplugin vom WordPRess in benutzung? Diese sind meist sehr Datenbanklastig und unnötig, da Statistiken extern (Google Analytics) besser und performanter laufen!
Nein, ich habe keine separates Stat-Plugin laufen. Früher hatte ich mal Semmelstatz, aber das läuft hier schon lange nicht mehr.
Allerdings werde ich mir am Wochenende trotzdem mal die Datenbank anschauen.
@ Timo
Ich habe 2 Dinge verwendet:
1) Den folgenden Code-Schnipsel in den Footer:
<?php echo $wpdb->num_queries; ?> <?php _e(‘queries’); ?>. <?php timer_stop(1); ?> <?php _e(‘seconds’); ?>
Damit erhält man die Gesamtzahl der Queries und die Zeit dafür.
2) Das Plugin Debug-Queries von Frank Bueltge:
http://bueltge.de/wordpress-performance-analysieren-plugin/558/
Damit bekommt man eine Liste der Datenbank-Queries und muss sich die raussuchen, die verhältnismäßig lange dauern.
Was hat du denn dort für einen Tarif?
Wenn du einen eigenen Server hast, kannst du die maximalen Datenbankabfragen bei df hochschrauben lassen. Musst es ihnen nur per email mitteilen, weil die wohl sicherheitshalber die immer etwas gedrosselt haben.
@Peer: schon mal die Zeit der Queries zusammengezählt. Mein Blog braucht bis zum Timerstop nämlich knapp 700 ms, die Queries selbst brauchen davon aber nur 30 ms. Der Rest ist die Initialisierung von PHP, das Parsen des Codes, etc … WordPress lädt verdammt viel Code bei jedem Seitenaufruf und genau deshalb sind Caches wie Supercache auch so wahnsinnig effektiv. Selbst mit nur einer Query würde es nicht wesentlich schneller gehen …
Klar können Plugins fiese Queries erzeugen, aber das ist dann eher kein Lastproblem, sondern fehlerhafte Programmierung.
Mein Blog liegt nun leicht unter 700 ms. Aber du hast recht, WordPress ist mittlerweile recht “fett” geworden. Wäre schön, wenn es auch in dieser Hinsicht mal Optimierungen geben würde.
Die Plugins erzeugen ja gerade durch suboptimale Programmierung eine höhere Last als evtl. notwendig. Wenn man sich manche Queries so anschaut wundert es nicht, warum manche Hoster da Alarm schlägt.
Und ich hab mich schon gewundert warum das manchmal so lange dauert die Seite anzeigen zu lassen.
Vielleicht solltest de auch mal schauen wie groß deinen Tabellen nun mittlerweile geworden sind. MySQL versucht bei einer Abfrage die betroffenen Tabellen zu Cachen (läd sie in den RAM). Wenn die Tabellen gesamt aber größer als der RAM sind, dann wird nacheinander gecached oder noch schlimmer (einzelne Tabelle passt nicht in den RAM), dann von Festplatte und das kann dann richtig lange dauern.
Dazu müsstest du aber wissen wieviel RAM dir zugesichert wird auf dem shared Server.
Allgemein kann man zur Datenbankperformance sagen – je größer der verfügbare RAM, desto schneller die DB
Also auf einer Seite (www.allthemedia.de) habe ich auf der Startseite 273 Datenbankabfragen. Im Artikel 119.
Ich habe auch schon viele Plugins deaktiviert, aber ich glaube es hat auch mit meinem Theme zu tun.
Hyper Cache setze ich nicht ein, da bei mir beim ersten mal die seite ohne css kommt (also ohne design). Keine Ahnung wieso
Paul
Das sind recht viele DB-Abfragen.
Gerade auf der Startseite scheint es das ein oder andere zusätzliche Feature zu geben.
Ich hatte keine Probleme mit Hyper Cache und bisher auch noch keine Infos von Lesern diesbezüglich bekommen.
Allerdings habe ich auch bei anderen Cache-Plugins von diesem Phänomen gehört. Woran es liegt, kann ich aber nicht sagen.
Hi, ich bin auch df.eu, was mich ein bisschen wundert ist, das du so nen grossen Blog nicht auf einen eigenen Server hostest. Bei sehr grosser Last kann es auch vorkommen, das Domainfactory das gesamte Angebot sperrt, um andere Kunden zu schützen. Ich hab übrigens einen Server bei denen, und bin seit 2001 zufriedener df.Kunde.