Photo von Google Rechenzentren
Ganz besonders dann, wenn mal nicht der User davor der Schuldige ist. Derzeit nämlich beschäftige ich mich mit der alles in allem ziemlich unbefriedigenden Performance dieses Blogs. Mit viel Glück gibt’s „schon“ fünf Sekunden nach Aufruf der Seite was zu sehen, mit weniger Glück dauert’s auch mal 20. Meistens liegt die Wahrheit irgendwo dazwischen. Und weil mir das nicht gefällt versuche ich seit geraumer Zeit, die Ursachen dafür zu finden. Mit bislang eher mäßigem Erfolg.
Bis dato habe ich eine Kopie der Seite (Code, Daten und Datenbank) auf zwei „richtigen“ Servern installiert, einer davon war definitiv mit nichts anderem beschäftigt als nur diese Seite zu bedienen. Der Erfolg dessen war mehr oder weniger gleich Null. Ob nun ein richtiger Dedicated Server bei 1 und 1 oder bei Host Europe, die Ladezeiten wurden nicht geringer. Je nach Tagesform war „das Original“ (bei 1 und 1 von einem unspektakulären Shared Hosting Account bedient) sogar schneller.
Danach hab ich angefangen, Plugins zu deaktivieren, also vermeintlich ressourcenfressende Zusatzfunktionen abzuschalten. Insbesondere solche, die auf externe Daten wie RSS-Feeds zugreifen, auf deren Performance ich keinerlei Einfluss habe. Auch das hat kaum eine Veränderung bewirkt, so dass ich ein paar Dinge wieder angeknipst habe: die Pinterest-Galerie, die Blogroll und den Feed meines Gartenblgs. Hat nicht merklich geschadet.
Und jetzt bin ich mit meinem diesbezüglichen Latein ziemlich am Ende.
Moin,
ich hatte das Problem vor ein paar Tagen mal gesehen, und es hat sich als Latenz gezeigt, d.h. der Server hat vor dem ersten Byte der Antwort erstmal 30 Sekunden schlafen gelegt. Also Antwortzeiten, ja sicher, aber in Form von Latenz.
Bei solcher Dauer einer Latenz kann man nicht davon ausgehen, dass irgendwas langsam ist, sondern dass der Server (die Anwendung, WordPress etc) auf eine andere Ressource wartet.
Mit zu hoher Last, oder zu langsamen Server, ist das nicht erklärt – zumindestens nicht auf einem eher mittelgut besuchten Blog 😉
Ich würde die Ursache des Problems jetzt eher in einer externen Ressource vermuten, theoretisch das DB-Pooling, gerne schleichen sich in die Source aber auch Abhängigkeiten ein, die man eigentlich nicht erwarten würde.
Sehr beliebt an der Stelle, aber fürchterlich unnötig: Die Source braucht irgendwas von einer anderen Site, und die ist down.
An der Stelle würde nur eine kleine Durchsicht des Codes helfen, ergänzend DB-Pooling prüfen, und mal schauen worauf der Server sich so normalerweise verbindet, z.B. mit netstat.
Ich weiss jetzt nicht, ob das hilft… Wollte das aber loswerden.
viele gruesse.
Servus Holger,
nun, ich kann mich selbst nicht wirklich zu den WordPress Experten zählen, aber wie mein Vorredner schon sagte dürfte die Zeit die für das PHP Rendering drauf geht recht interessant sein. Viel wichtiger wäre für mich jedoch noch die Zeit die zwischen Datenbank Login (ich tippe mal auf MySQL) über die Abfrage der Daten bis zum Logout aus der Datenbank vergeht.
Sollte sich zeigen dass der Login und der Logout überdurchschnittlich lange dauern, die Daten aber zügig kommen, dann wurde etwas begrenzt um ein Login Flooding zu verhindern. Dagegen kommst du mit „persistent database links“ (mysql_pconnect) an wenn das der Hoster erlaubt und WordPress unterstützt. Dann bleibt für jede Session die Datenbankverbindung offen und das ständige Login/Logout an der Datenbank entfällt.
Ist es anders herum, also tröpfeln die Daten nur byteweise aus der Datenbank, dann ist das Ding überlastet ODER dein WordPress greift über Muster auf deine Datenbank zu für die sie nicht optimiert ist. Da hilft wohl nur heraus zu finden welche Abfragen WordPress macht und die Datenbank entsprechend zu optimieren, sofern man die Möglichkeit beim Hoster dazu hat.
Hast du nen Dedi für dich allein? Dann kannst du natürlich selbst alles schrauben… 🙂
Ansonsten kann ich Hetzner als Hoster mit gutem Gewissen sehr empfehlen…
MfG
Gizmo
Hallo Holger,
ich habe schon mehrmals Fotos auf „feedback@holgerbarske.com“ gesendet,
zuletzt Gestern 2 Fotos von „Real Horns“. Gibt es da eventuell einen Zusammenhang mit dem oben beschriebenen Problem,oder liegt es an meiner Person. Falls die Fotos oder Links generell nicht ankommen würde ich sofern überhaupt Interesse besteht zukünftig an „barske@brieden.de“ senden“, denn da scheint es ja zu funktionieren?
Grüße aus dem Schwabenland
Roberto
Hi Holger, ich würde erst mal einen Monitor draufsetzen, um zu schauen, ob sich die Antwortzeiten mit deinen Usertrackinginfos decken. Vielleicht ist es gar nicht dein System. Als freies Tool z.B. https://www.pingdom.com/free/.
Dann gibt es einige Performance und Caching Tools, aber das wirst du sicher bereits probiert haben.
Zur Info. 5,53 Sec Waiting bis zum ersten KB load, der rest sieht ganz gut optimiert aus, nix über 100 KB, alles innerhalb von 2 sec geladen. Somit 8 Sec für alles – das ist nicht gerade schnell.
Ansonsten mal die Renderingtime der PHP-Seiten prüfen.
$time_start = microtime(true);
$time_end = microtime(true);
$time = $time_end – $time_start;
echo „Displaying the render time: $time seconds\n“;
Gruss
Jens
Moin Holger!
Ich erlebe hier nicht die von Dir bemängelten Zeitverzögerungen – eventuell etwas, was räumlich stark unterschiedlich auftritt?
Viele Grüße,
Georg
Bei mir ist’s tagesformabhängig: meistens zügig, gelegentlich grottenlangsam.
Ich würder mal die Betreiber von hokuwo.de fragen, wie sie das System aufgesetzt haben. Die werden beim Anbieter der Blogsoftware als Refernz angeführt, und da läuft alles auch sehr zügig.
Das ist interessant. Zumal das auch nur ein doofes WordPress ist (wie hier auch) und sogar das „Theme“, also die grafische Oberfläche die gleiche ist. DAs geht recht zügig, das stimmt; allerdings hält sich der Betreiber in Sachen Ausstattung auch ziemlich zurück.