Das Bestatterweblog ist eines der beliebtesten Blogs Deutschlands. Auch aus Österreich, der Schweiz und den Benelux-Ländern habe ich hier viele Besucher.
Das erste Mal machte mich mein väterlicher Freund Frédéric darauf aufmerksam, daß er nicht immer die neuesten Inhalte angezeigt bekommt.
Ich führte das zunächst auf ein lokales Browserproblem zurück.
Doch kurz vor Weihnachten und darüber hinaus mehrten sich die Meldungen freundlicher Leserinnen und Leser, die ebenfalls unter dem Aktualisierungsproblem leiden.
Symptom: Es erscheinen hier neue Artikel im Blog, sie werden jedoch nicht in den Browsern der Leserinnen und Leser angezeigt. Dort steht irgendein alter Artikel hartnäckig als letzter Artikel ganz oben.
Ja, manche haben schon gedacht, ich sei erkrankt, verstorben oder von Aliens entführt worden.
Glücklicherweise trifft nichts davon zu, obwohl mich die angeblichen Sex-Experimente der Aliens in meiner Phantasie beflügeln …
Wie ich eingangs schrieb, ist das Bestatterweblog ein sehr stark frequentiertes Blog.
So kommen wir nicht umhin, mit verschiedenen Methoden dafür zu sorgen, daß das Blog unter nahezu allen Umständen möglichst schnell an die Benutzer ausgeliefert wird.
Das versuchen wir durch sauberen Code und vor allem einem klugen Caching zu bewerkstelligen.
Zum Caching muß man folgendes wissen:
Das Bestatterweblog läuft mit WordPress. WordPress erzeugt, wie viele CMS-Systeme, dynamische Seiten.
Festgelegt ist jeweils nur die Reihenfolge und das Aussehen der Objekte (Texte, Bilder, Gestaltungsbefehle), diese werden aber bei jedem Seitenaufruf „just in time“ jedes Mal aus der Datenbank abgerufen und neu zusammengesetzt.
Das erzeugt also bei jedem Seitenbesuch eine gewisse Serverlast. Im Einzelnen ist das nicht viel, der Server ist entsprechend leistungsfähig. In der Summe, vor allem wenn neue Artikel erschienen sind, kommen aber so viele Besucher gleichzeitig, daß unser Geschick und die schnelle Technik nicht ausreichen, um alle gut und schnell bedienen zu können.
Deshalb setzt man auf das sogenannte Caching. Dabei werden die Inhalte nicht mehr jedes Mal dynamisch generiert, sondern als feste HTML-Dateien vorgespeichert und können schneller an die Browser der Benutzer ausgeliefert werden. Das ist in etwa so, als wenn man bei McDonalds zügig aus der Warmhaltetheke bedient wird und nicht auf den Zusammenbau des Burgers warten muß.
Es gibt für WordPress sehr gute, gut dokumentierte und erprobte Plugins für das Caching.
Ich habe sie alle ausprobiert und jeweils über längere Zeit im Einsatz gehabt.
Anfangs laufen sie alle immer problemlos und bringen den erhofften Geschwindigkeitsvorteil.
Nach einer Weile jedoch zeigt sich immer das gleiche Bild:
Die Plugins stören mehr, als daß sie nützen.
Sie verlangsamen das Backend und ich kann nur noch unter Erschwernissen arbeiten.
Sie produzieren falsche Seitenimpressionen, d.h. der Besucher sieht veraltete Inhalte.
Sie beginnen Probleme bei der Darstellung zu machen, weil das CSS-Minifying nicht mehr funktioniert.
Man beginnt dann die Fehlerquellen nach und nach zu suchen, was an sich schon sehr aufwändig ist.
Da aber diese Cachingprogramme immer auf verschiedenen Ebenen laufen, ist es nicht ganz leicht, die Stelle zu finden, die für ein bestimmtes Fehlerverhalten zuständig ist.
Außerdem bestehen die Konfigurationsanweisungen aus einem internen Teil, der auf WordPress-Ebene abgehandelt wird, dem eigentlichen gecachten Inhalt und den Anweisungen, die die Programme z.B. in die Steuerdatei htaccess schreiben.
Wo soll man da suchen?
Letztlich führt es immer wieder dazu, daß man die Programme erst Stück für Stück und schließlich ganz abschaltet.
Im Google-Speed-Ranking sackt man dann aber unweigerlich von A/A auf F/G ab.
Ein Dilemma. Ein Teufelskreis.
Hat man alles abgeschaltet und in der htaccess alles auskommentiert, dauert es irgendwie gefühlt immer Wochen, bis bei allen Nutzern alles wieder rund läuft, weil deren Browser oft noch alte Anweisungen behalten haben und sich nicht mit neuen Inhalten füllen.
Was die Einstellungen der Caching-Plugins betrifft, so könnt Ihr mir glauben, daß ich da alle Dokumentationen gelesen habe und daß alles richtig voreingestellt ist.
Ich habe keine Ahnung, warum das nicht wirklich rund läuft. Vor allem, warum es anfangs immer gut funktioniert und dann im Laufe der Zeit „abschmiert“.
Nun haben wir seit einer Woche alles, was für die Aktualisierungs-Problematik in Frage kommt, abgeschaltet.
Dennoch klagen die User weiter über alte Artikel an neuester Stelle.
Zunächst kann ich von hier aus nur den Rat geben, einmal den Browsercache zu löschen, beherzt F5 zu drücken und die Seite neu zu laden.
Wer noch irgendeine Idee zu dem Thema hat: Immer her damit!
Ich habe noch einmal die wichtigsten Schlagwörter (Hashtags) dieses Artikels für Sie zusammengestellt, damit Sie sich besser orientieren können:
Keine Schlagwörter vorhanden
Hugo (https://gohugo.io/) find ich derzeit recht spannend, da ist caching quasi systeminhärent 😀
Gilt allerdings nicht für die Kommentare, die müssen dynamisch nachgeladen werden, keine Ahnung was der Google-Algorithmus davon hält.
@Carsten: Schau ich mir an, danke.
Es könnte am sogenannten „Expire“-Header liegen.
Ich habe die Seite mal bei web-sniffer.net getestet – es ist kein Zeitpunkt ausgegeben, an dem der Inhalt abläuft. Das heißt: Ein Browser weiß nicht, ab welchem Zeitpunkt er eine Seite komplett vom Server abholen soll. Er holt sie deshalb aus dem Browser-internen Cache ab und das kann recht veralteter Inhalt sein.
Nachtrag: Ich habe eine .htaccess-Datei mit Regeln für alle meine Webseiten ins oberste Hosting-Verzeichnis (heißt bei mir /html/) gelegt. Sämtliche Seiten, die darin liegen, nutzen nun diese Regeln. Hier der Teil mit dem Expire-Header:
— SCHNIPP —
ExpiresActive On
ExpiresDefault „access plus 2 hours“
ExpiresDefault „access plus 1 week“
— SCHNAPP —
Damit werden Browser angewiesen, standardmäßig nach 2 Stunden nachzusehen, ob es auf dem Server neue Inhalte gibt. Eingeschränkt sind Scripte, Bilder und so weiter – da reicht eine Woche Ablaufzeit, denn die ändern sich eigentlich nicht so oft.
Mal als Ansatz zum Probieren. 🙂
Ich wusste es – der Code wird zerhackt. 🙁
Hier gibt’s ihn in voller Schönheit:
https://www.dropbox.com/s/advuuh8gbovm8ub/htaccess.txt
@NetzBlogR: Danke für Deine Mühe, aber das ist derzeit irrelevant, weil die entsprechenden expire-Anweisungen nur jetzt zur Problemanalyse abgeschaltet sind.
Gibt es hier vielleicht jemanden, der mitliest und sich mit der Materie auskennt? Würde mich auch mal interessieren was das Problem und natürlich die Lösung ist.
So als Halb-Weisheiten-Verbreiter:
Wenn das System fertige HTML-Seiten baut und cached, werden die sicherlich ja irgendwo „niedergeschrieben“ und gespeichert. Vielleicht in eine Art TEMP oder CACHE-Verzeichnis auf dem Server? Vielleicht läuft das mal voll und sollte regelmäßig (1x im Monat) geleert und vom CMS neu aufgebaut werden? Kann man das im CMS-Plugin vielleicht einstellen? Könnte so etwas sein?
@Held in Ausbildung: Ja, wir haben den Cache regelmäßig jede Nacht geleert. Das war notwendig, weil sonst das System kontraproduktiv langsamer wurde.
Also mit w3 total cache gab es auf unseren Seiten nie Probleme. Nervig ist nur, dass man nach jedem Beitrag bzw. jeder neuen Seite erstmal den WP cache leeren muss damit er alles ordentlich generiert.
Aber wenn Ihr die Doku gelesen habt kann’s daran ja nicht liegen..
Wie sieht’s denn mit der Serverauslastung und der WP-config aus?
P.S. Richtig störend wird’s dann erst bei Magento, das ändert garnichts ausser man Klickt sich durch’s halbe Backend und leert alles.
@unbekannt: W3TC ist mein persönlicher Favorit, gehört aber leider zu den Kandidaten, die irgendwann in die Knie gehen. Ich meine, es ist ja so: Man stellt die für sich optimalen Parameter in der Konfiguration ein und dann sollte es doch mit diesen Einstellungen reibungslos laufen. Tut es auch, aber eben nur ein paar Wochen/Monate, dann geht’s eben leider nicht mehr.
@Peter Wilhelm: Auf die Gefahr hin, dass ich mir hier wirklich mein Grab schaufle (was ich in meinem desolaten Zustand nicht in angemessener Zeit schaffe): habt Ihr mal die error-logs durchgesehen?
Wir haben auch schon tagelang überlegt was es sein könnte obwohl es nach einem kurzen Blick in die Logfiles dann ganz klar war.
Ansonst vielleicht ein groesserer Server? Load balancing? Vielleicht wird auch ein CDN benutzt und da laeuft etwas schief? Leider hab ich ja keine Ahnung wie die Besucherzahlen vom bestatterweblog so aussehen. 🙂
Auch ich hatte genau dieses Problem. Teil 16 des Gewinnspiels wurde mir bis Weihnachten als Startseite angezeigt (daher auch das Gewinnspiel verpasst 🙁 ) Irgendwann habe ich die Hintertür probiert und bin über den Dreibeinblog auf die neuesten Beiträge im Bestatterweblog gestoßen. Von dort habe ich mich dann weitergehangelt… Nach dem Löschen des Browser-Cache scheint alles wieder zu funktionieren. Vielen Dank!
Ja, beim Gewinnspiel kam ums Verrecken nicht der letzte Teil am 23., insofern war dann alles für die Mieze…
Daß was mit dem Cache faul ist, fiel mir aber erst auf, als erst der letzte Teil vom Gewinnspiel da war, dann aber wieder weg und auch noch das davor.
Wahrscheinlich liest die NSA mit (die wollen ja auch mal lachen und nicht dauernd nur so fades Politikergesabbel konsumieren) und hat was falsch gemacht… 😛
Also als Web-Entwickler stößt man immer wieder mal auf das Problem…
– Ansätze:
Tastenkombination: [Strg] + [F5] (erzwingt neuen Abruf vom Server)
(kann bei manchen Versionen auch [Shift] + [F5] (oder: [Shift] + Klick auf reload.Icon) sein)
User stellen das Caching auf eine andere Stufe, guck hier beschrieben:
https://www.philognosie.net/index.php/tip/tipview/646/
@wool:
Das hatte ich auch bereits mehrfach probiert, zum Schluß blieb die Seite ganz ohne Inhalt. Nein, nicht einfach nur weiß, sondern alles war da, nur in der Mitte gab es keine Beiträge… Sehr kurios
@Held in Ausbildung: Aktuell?
@Peter Wilhelm:
Nee seit den letzten Tagen scheint es besser zu sein. Will es nicht beschreien… Aktuell ist „Voll der krasse Scheiss“ mein letzter/neuester Artikel…
Dass bei einzelnen usern keine neuen Inhalte erscheinen klingt mir eher nach einem caching auf Seite des Browsers. Da sollte die Tastenkombination STRG+F5 zur Not helfen.
Wie war der expires Header denn gesetzt sind die Probleme bestanden? Dass er nun nicht mehr Gesetz wird ist ja dem Browser egal, wer bedienz auch weiter aus seinem Cache.
Das lokale caching wird außerdem nicht nur serverseitig beeinflusst, sondern auch durch Einstellungen im Browser. Besonders in Internet Explorer lässt sich (leider) viel dazu ein-/verstellen…
Ich hatte das Problem auf dem Rechner im Büro, einfach nur F5 hatte nichts gebracht, ich habe dann (weil ich dank Email-Benachrichtigung ja wusste, dass neue Artikel da sind), einfach im Firefox die Cookies des Bestatterweblog gelöscht. Das hat geholfen.
@Sascha: Cookies löschen und neu laden hat bei mir leider nicht geholfen.
Da ich jetzt das Problem kenne (als ich durch Zufall was im Archiv gesucht und dabei festgestellt hab, daß es ja viel mehr Januarbeiträge gibt, als ich kannte), gehe ich halt übers Archiv rein, aber schöner wäre es schon, wenn es wieder „normal“ funktionieren würde.
Das Problem kann ja nicht auf User-Seite gelöst werden – ein Force-Reload ist auch nur dann sinnig, wenn der Server aktuell ausliefert.
Von unseren Installationen diverserlei Systeme, propietär und „von der Stange“ weiß ich, daß externe Caches sehr zuverlässig laufen. Damit meine ich Caching, was NICHT von der ursprünglichen Webseite erledigt wird, sondern von einer davorgeschalteten Instanz – das kann auch auf dem gleichen Server sein, oder ein ganzes CDN.
Nur mal so am Rande. Peter, das ist hier ein privat geführtes Blogdings. Ich finde es einfach grossartig, wie viele Mühe du dir gibst. dass das alles läuft. Andere buchen irgendein Fertigblog bei blogger oder so und du hast einen Server mit eigener Software und machst das damit wir ein ordetliches Leseerlebnis haben.
Auch nicht selbstverständlich. Dafür lass ich mal deine Kaffeekasse klingeln.
Danke!!!!!!
Ich hatte das Problem auch, und dachte es läge an meinem Browser. Bisher hat allerdings schon nur ein zusätzlicher Klick auf den Aktualisierungsbutton immer geholfen, und ich hab kein Problem damit das weiterhin zu tun, solange ihr das Problem nicht in den Griff kriegt.
Hallo Peter, Auf welchen Wert wurde denn der expiry Header gesetzt bevor ihr ihn nun wieder deaktiviert habt? Das Problem daran ist nämlich, dass der Browser die Seite in seinem Cache ablegt und vor erreichen des Datums aus dem Expiry HEader idR gar nicht mehr am Server anfrägt. Den Betroffenen hilft dann auch das serverseitige deaktivieren der Caching-Direktiven nichts. Auch ein Clink auf „neu laden“ oder das Drücken derTaste F5 helfen dann oft nicht (Wird vom Browser oft ignoriert wenn die Seite im Cache liegt). Allerdings hilft dann meist die Tastenkombination STRG+F5, da hierbei der Brwoser dann auch seinen Cache zur betreffenden Seite leert. Richtig fies und kaum Nachvollziehbar wird das ganze dadurch, dass v.a. der internet explorer noch dazu Einstellungsmöglcihkeiten bietet, die enteweder dazu führen, dass vom Browser gar nicht gecached wird oder trotzdem noch gecached wird wenn der Server das garnicht signalisiert. (Beispiel IE11: Extras > Internetoptionen > Allgemein; dort bei Browserverlauf auf „Einstellungen“ gehen. Der Punkt lautet „Neuere Versionen der gespeicherten Seiten suchen“. „Nie“ und „Automatisch“ sind teils problematisch). Es wäre interessant,… Weiterlesen »
Das sah so aus:
#
# AddType font/x-woff .woff
# ExpiresActive On
# ExpiresDefault "access plus 1 day 1 hour"
# ExpiresByType image/x-icon "access plus 1 year"
# ExpiresByType image/ico "access plus 1 year"
# ExpiresByType image/gif "access plus 7 days"
# ExpiresByType image/png "access plus 7 days"
# ExpiresByType image/jpg "access plus 7 days"
# ExpiresByType image/jpeg "access plus 7 days"
# ExpiresByType text/css "access plus 1 day 1 hour"
# ExpiresByType application/javascript "access plus 30 days"
# ExpiresByType application/x-javascript "access plus 30 days"
# ExpiresByType font/x-woff "access plus 10 days"
#
@Peter Wilhelm: Hallo Peter, Dein Server hat also alles was nicht explizit anders definiert wurde mit einem Ablaufdatum von 25 Stunden ausgeliefert (ExpiresDefault). Die Seiten selbst haben den Content-Type „text/xml“. Und dafür wurde keine Außname (ExpiresByType) definiert. Der Browser des Nutzers wird also angewiesen frühestens nach 25 Stunden wieder nach einer neuen Version der Seite zu fragen. Ist das bewusst so lange gewählt? Das ist schon sehr lange 😉 [Just in Case: die Angaben stellen Anwesungen des Servers an den Browser dar und sorgen nicht dafür, dass der Server selbst irgendwas cached, statt es immer neu zu errechnen] Wenn STRG + F5 geholfen hat deutet das definitiv darauf hin, dass der Browser der Meinung war noch eine ausreichend aktuelle Seite im eigenen Cache zu haben (was aber nicht den Tatsachen entspricht). Durch dier Tastenkombination wird der Browser dann überredet dennoch die aktuelle Version vom Server zu holen. Da müsste man bei einem Betroffenen mal den Browser Cache näher anschauen, allerdings weiß ich da jetzt offen gestanden auch nicht wirklich wie das geht. Ich hoffe ich… Weiterlesen »
@Sebastian: Cookies löschen hat ja wie schon geschrieben bei mir nichts gebracht, neu laden auch nicht, aber Strg + F5 hilft bei mir, danke! (nutze Firefox Version 42.0, falls das bei der Fehlersuche irgendwie hilft)
Bei mir erschien als letzter Beitrag immer wieder nur „Bares für Rares“ vom 11.1.
Und heute finde ich plötzlich all die anderen Beiträge und war erstmal schwer überrascht, dass es dazu auch „alte“ Kommentare gibt.
Ich hab zwar überhaupt keine Ahnung von solchen Programmier-Problemen und kann daher natürlich überhaupt nix dazu sagen. Aber ich hatte mir schon richtig Sorgen gemacht, dass etwas passiert sein könnte und bin sehr froh, dass es wenigstens keine gesundheitlichen Probleme sind.
Lieben Gruß 🙂
Ist mir vor Weihnachten auch aufgefallen, aber ich dacht mir, ist bestimmt bekannt, und ich hab auf die Mail verzichtet… 😉 Seit heute gehts aber wieder, vorher war F5 notwendig.
Blöde Frage: Reden wir hier nur von reinem HTML Caching? Ich hatte mal nette (und kaum zu findende) Probleme mit memcached, der auf ner anderen Ebene arbeitet (häufig benutzte Daten werden im Arbeitsspeicher gehalten, damit lassen sich dann die dynamischen Seiten schneller erstellen). Keine Ahnung, ob irgendwelche Plugins (oder WordPress selber?) davon auch Gebrauch gemacht haben, aber mir kommt das Problem, dass nach einiger Zeit dann irgendwie gar nix mehr so richtig will, von dem Teil bekannt vor… Nach nem Neustart dieses Dienstes liefs dann wieder wie direkt am Anfang, woran er sich bei mir konkret verschluckt hat hab ich aber auch noch nicht rausgefunden…
Ich hatte auch schon die schlimmsten Befürchtungen, habe dann aber durch irgendeinen Zufall gesehen, dass in den anderen Blogs, die ich nicht lese, etwas passiert. Also konnte es nichts Lebensbedrohliches sein. Aber ich habe jeden Tag brav bei meinem Chrome nach neueren Inhalten seit den Neujahrswünschen gefragt und immer wieder wurde mir nur ein frohes, neues Jahr gewünscht und der Tod von Lennie Kilminster betrauert. Ich habe dann einfach wieder von vorne angefangen und gehofft, dass es irgendwann wieder neue Beiträge geben wird. Und heute habe ich sie durch einen Zufall gefunden. Juhuu!
Man wird sich ja noch Sorgen machen dürfen! 🙂
Aber hallo… Cache leeren….. Das wars.
Jetzt kann ich wieder mitlesen.
Danke an alle !!!!!!