Closed ghost closed 12 years ago
leofeyer
commented
12 years ago Bei abgeschaltetem Browsercache scheint der Fehler nicht aufzutreten.
Genau so ist es, denn das "Problem" wird durch den Cache und nicht durch TYPOlight verursacht.
--- Originally created on September 16th, 2009, at 11:29am
ghost
commented
12 years ago Das heisst, die Seiteneigenschaft "Cache erlauben" bezieht sich gar nicht auf den serverseitigen Cache von TYPOlight, sondern nur auf eine Anweisung an den Browser?
Wenn ich "Cache erlauben" für die Seiten ausschalte, tritt das Problem ja grundsätzlich nicht auf.
Ich war bisher der Meinung, dass "Cache erlauben" definiert, ob Seiten von TYPOlight gecached werden, meines Wissens in /system/tmp.
--- Originally created by okapi on September 16th, 2009, at 12:26pm
leofeyer
commented
12 years ago Cache erlauben bedeutet, dass eine Seite zwischengespeichert werden kann. Das geschieht sowohl auf Serverebene, als auch durch Senden eines entsprechenden Headers auf Clientebene.
--- Originally created on September 16th, 2009, at 12:29pm
ghost
commented
12 years ago Danke für die Erklärung.
Nachdem ich dem FE-User nicht vorschreiben kann, was er mit seinem Browser anzustellen muss, damit er die Seite richtig dargestellt bekommt, bedeutet das also, dass das TYPOlight Cachesystem bei Verwendung von geschützten Seiten generell nicht einsetzbar ist.
Warum auch immer, aber TYPO3 bin ich mit diesem Problem nicht konfrontiert.
--- Originally created by okapi on September 16th, 2009, at 12:55pm
leofeyer
commented
12 years ago Das hast Du glaube ich nicht richtig verstanden. Aber dann nimm doch einfach TYPO3 :)
--- Originally created on September 16th, 2009, at 01:00pm
ghost
commented
12 years ago Ich glaub ich habs dann auch noch nicht ganz verstanden... Was ich mir denken könnte mit meinem Beschränkten Wissen: Da Browsercache und Servercache unterschiedlich sind, könnte man diese doch separieren:
Viele Grüße
--- Originally created by MacKP on September 16th, 2009, at 02:02pm
ghost
commented
12 years ago Leo, deine Antwort lässt mich jetzt schon ein wenig ratlos zurück.
Ich arbeite mit TYPO3. Aber weil die Performance auf einem shared server nicht sehr befriedigend ist, bin ich auf der Suche nach einer Alternative. Von TYPOlight bin aus vielen Gründen sofort begeistert gewesen (nicht wegen dem "TYPO" im Namen), sowie von den äusserst hilfsbereiten und netten Forumsmitgliedern.
Ich denke, ich habe gemacht, was ich tun konnte. Ich habe das Problem im Forum sehr ausführlich geschildert, ich habe es an der Online-Demo positiv getestet, man hat mir geraten, ein Ticket diesbezüglich zu erstellen, was ich auch getan habe, nicht ohne zuvor eine Bestätigung des geschilderten Verhaltens durch einen anderen erfahrenen Forumsteilnehmer abzuwarten.
Jetzt erfahre ich vom Entwickler persönlich, der Browser sei schuld. Und dann, ich habe das (?) nicht richtig verstanden.
Ich will einfach nur meine Seite umsetzen. Da gibt's nun mal einen öffentlichen und einen geschützten Bereich. Den öffentlichen möchte ich aus Performancegründen mit Cache fahren. Ich denke, das sind keine sehr exotischen Ansprüche. Wenn's mit TYPOlight nicht machbar ist, dann ist es eben so, aber ich möchte gerne wissen.
Michael
--- Originally created by okapi on September 16th, 2009, at 02:25pm
leofeyer
commented
12 years ago Hi Michael, tut mir leid, wenn Du meine Antwort in den falschen Hals bekommen hast. Das "bei TYPO3 funktioniert es aber"-Argument ist halt einfach hier nicht besonders gern gesehen :)
Ich kann Dein Problem jedoch nicht so ganz nachvollziehen, deswegen habe ich auch geschrieben, dass Du hier eventuell etwas falsch verstanden hast. TYPOlight nutzt sowohl den Browser- als auch den Servercache, um eine optimale Performance und Serverbelastung zu erreichen. In dem Moment, in dem Du Dich anmeldest, schaltet sich der Servercache ab. Sofern Du vorher schon Seiten aufgerufen hast, werden diese unter Umständen direkt aus dem Browsercache geladen. In diesem Fall musst Du einmal auf "Aktualisieren" klicken, damit Firefox weiß, dass er die Seiten neu anfordern soll.
Es würde mich wundern, wenn das bei TYPO3 anders wäre, denn soweit ich weiß, kann man den Browsercache nicht aus einer PHP-Anwendung heraus beeinflussen.
--- Originally created on September 16th, 2009, at 03:23pm
fbender
commented
12 years ago Die Situation ist ja folgende: Man ruft eine Seite A auf, diese wird in TL je nach Einstellung in den Cache geschrieben (sagen wir mal 6h). Gleichzeitig sendet TYPOlight an den Browser die Anweisung, dass die Seite A 6h lang gültig ist. Jetzt meldet man sich an, dabei erscheint ein neuer Menüpunkt. Der Browser weiß aber nicht, dass er Seite A jetzt erneut laden muss, um sich der aktuellen Situation (Nutzer angemeldet) "anzupassen", weil er denkt, dass die Seite noch weitere 6h lang gültig ist. Die Seite A ist ja auch immernoch gültig, aber nur für nicht angemeldete Besucher. Komliziert. Schnellste Lösung wäre eine geringe Cache-Zeit (< 5 Minuten), wobei man dann in Kauf nehmen muss, dass es manchmal zu Verzögerungen bei Aktualisierung von bestimmten Seiten kommt.
Mehr Möglichkeiten hätte man auf jeden Fall, wenn man die Einstellung für Browser-Cache und TYPOlight-Cache unabhängig festlegen könnte (insofern jetzt ein Feature Request ;-) ). Damit könnte Seite A für nicht angemeldete Besucher TL-intern gespeichert werden, der Browser aber weiterhin immmer die aktuelle Seite ausgeliefert bekommen.
Aber das Problem sollte man IMO anders angehen. Dafür gibt es mehrere Möglichkeiten, und natürlich stellt sich da die "light-Frage".
"light" wäre auf jeden Fall folgendes: Es gibt ja den Header "IfModifiedSince", der dafür sorgt, dass der Browser, nur wenn benötigt, seinen Cache mit aktuellen Daten füllt. Das wäre die sinnvollste Methode für ein Cache-System. Ich weiß jetzt nicht, wie das mit absoluten Expire-Headern zusammenarbeitet, würde aber vermuten, dass, wenn letztere gesendet werden, kein IfModifiedSince-Header bei einem neuen Request gesendet wird. Da müsste man angreifen. Ich wüsste aber auch nicht, wie man IfModifiedSince per PHP behandeln soll bzw. ob das überhaupt geht.
Ich könnte jetzt noch ein bisschen weitermachen, aber das würde hier grade den Rahmen sprengen (und meinen Zeitplan). Später mehr, vllt. im Forum.
--- Originally created on September 16th, 2009, at 05:25pm
ghost
commented
12 years ago Hallo Leo, danke, dass du dir die Zeit genommen hast, die Cache-Strategie von TYPOlight zu erläutern! Vielleicht könnte das auch Eingang in die Dokumentation finden? Mir geht es bestimmt nicht um plumpe Vergleiche von Systemen, vielmehr um Erkenntnis und um die Suche nach Möglichkeiten zur Umsetzung von Vorstellungen.
Für mich hat FloB mit dem oben stehenden Posting genau das formuliert, was ich mir - sehr laienhaft - zusammengereimt habe.
Es gibt also a) den serverseitigen Cache von TYPOlight, der im Dateisystem (/system/tmp) abgelegt wird, und es gibt b) die HTTP-Header-Anweisung an den Browser, ob oder wie lange dieser Seiten cachen soll.
Wäre es nicht wünschenswert, dass TYPOlight im Falle eines angemeldeten Users die Header-Anweisung "kein Browser-Cache" (sinngemäß) übermittelt?
Du sagst nun: "...soweit ich weiß, kann man den Browsercache nicht aus einer PHP-Anwendung heraus beeinflussen..."
Das wundert mich eigentlich sehr, denn ich denke mir, wer soll denn sonst die Header-Anweisungen an den Browser schreiben, wenn nicht die betreffende PHP-Anwendung?
Ich weiss noch nicht, wie andere Systeme diese Sache handhaben, ich werde ich mir die jeweiligen Header-Informationen anschauen. Bestätigen kann ich allerdings, dass dieses Browser-Cache-Problem bei den bisher von mir in diese Weise (geschützte User-Bereiche) verwendeten Systemen wie TYPO3 oder WebsiteBaker noch nie aufgetreten ist.
Wenn der Browser-Cache aus der PHP-Anwendung nicht beeinflussbar wäre, wie könnte denn dann überhaupt die klassische aktuelle Information: "Sie sind angemeldet als User XY" übermittelt werden?
Gruß Michael
--- Originally created by okapi on September 16th, 2009, at 11:20pm
fbender
commented
12 years ago Wäre es nicht wünschenswert, dass TYPOlight im Falle eines angemeldeten Users die Header-Anweisung "kein Browser-Cache" (sinngemäß) übermittelt? Das tut TL auch. Nur weiß TL, bevor man sich anmeldet, nicht, dass sich ein User anmelden wird und der Inhalt der Seite sich verändern wird – und sendet dann, solange der User noch nicht angemeldet ist, die eingestellte Lebensdauer der aufgerufenen Seite. Sobald ein Nutzer angemeldet ist, wird (AFAIK) übermittelt, dass jede Seite komplett neu geladen werden muss, und nicht aus dem Cache. Der Browser hat aber die Information, dass die Seite, die er gespeichert hat, noch gültig ist, und kommt gar nicht erst dazu, eine neue Anfrage zu stellen, ob die Seite noch aktuell ist (denn er verlässt sich ganz auf die übermittelte Lebensdauer der Seite).
Du sagst nun: "...soweit ich weiß, kann man den Browsercache nicht aus einer PHP-Anwendung heraus beeinflussen..." Die Aussage ist falsch und richtig. PHP kann den Browsercache nicht beeinflussen, wenn dort erstmal Daten drinne sind. Bei neu hinzukommenden Daten (also dem ersten Aufruf einer unbekannten Seite) kann per PHP gesagt werden, dass eine Seite eine gewisse Lebensdauer hat und nach einer gewissen Zeit "abläuft" – nach diesem Zeitpunkt muss die Seite neu vom Server angefordert (und gespeichert) werden – oder nicht im Cache gespeichert werden soll. Aber man kann sich auch nicht immer darauf verlassen, dass die Browser genau das machen, was man ihnen sagt ;).
--- Originally created on September 17th, 2009, at 12:39am
ghost
commented
12 years ago FloB, das ist wirklich sehr informativ und verständlich. Danke
 Frage, warum sich diese Problematik für mich bei TYPO3 noch nie gezeigt hat. Es ist definitiv noch nie ein Link temporär aus der Navigation verschwunden)
Die Seite läuft produktiv, auf Wunsch kann ich gerne einen Test-FE-Account einrichten.
Michael
--- Originally created by okapi on September 17th, 2009, at 01:26am
leofeyer
commented
12 years ago Du sagst nun: "...soweit ich weiß, kann man den Browsercache nicht aus einer PHP-Anwendung heraus beeinflussen..." Das wundert mich eigentlich sehr, denn ich denke mir, wer soll denn sonst die Header-Anweisungen an den Browser schreiben, wenn nicht die betreffende PHP-Anwendung?
Das ist auch nicht exakt von mir formuliert gewesen. Natürlich kann ich in einer PHP-Anwendung die entsprechenden Header setzen, um den Browser-Cache zu steuern. Wenn eine Seite aber mal im Browser-Cache liegt, wird sie ja direkt von dort wieder geladen und die Anfrage kommt gar nicht mehr bis zum Server bzw. der PHP-Anwendung.
Theoretisch müsste ja folgendes passieren: Der Benutzer öffnet die Seite und der Browser schreibt sie in seinen Cache. Der meldet sich der Benutzer an und jetzt müsste das PHP-Skript eigentlich auf Firefox zugreifen und dort die entsprechenden Cache-Einträge löschen. Dieser Zugriff ist aber meines Wissens nach nicht mit PHP möglich.
Vielleicht nutzt TYPO3 JavaScript für die Leerung des Caches? Ich weiß allerdings nicht, ob es mit JavaScript generell funktioniert. Vielleicht schickt TYPO3 auch die Cache-Header für den Browser überhaupt nicht, was dann natürlich weniger effektiv wäre.
--- Originally created on September 17th, 2009, at 10:27am
ghost
commented
12 years ago Hallo Leo, danke für die Antwort
![]( Jetzt beginne ich endlich, die Sache zu verstehen. Ich habe mir die HTTP Header von TYPO3 angeschaut: Du hast richtig vermutet, TYPO3 schickt überhaupt keine Cache-Header. Also weder den Eintrag "Cache-Control" noch "Expires".
Bei einem anderen CMS, concrete5, sieht "Cache-Control" im Header z. B. so aus: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Jetzt ist mir klar, warum das "Problem" bei den genannten CMS nicht auftritt. Ich verstehe jetzt auch, dass es sich, genau wie du gesagt hast, um gar kein Problem handelt.
Ich habe gelernt, dass sich die für die TYPOlioght-Seiten einstellbare Cache-Speicherzeit nur auf den Browser-Cache bezieht. Vielleicht ist das auch anderen Usern nicht gleich klar - ein Vorkommen des Wortes "Browser" im kontextbezogenen Hilfetext wäre vielleicht ein nützlicher Hinweis.
Ich habe mir jetzt so geholfen, dass ich die Cache-Verfallszeit auf 15 Sekunden gestellt habe. Das "Problem" tritt damit nicht mehr auf, und ich hoffe, dass TYPOlight nach Abmeldung des FE-Users den Browser wieder aus dem Cache des Dateisystems bedient (/system/tmp).
Nochmals herzlichen Dank für deine Geduld und die ausführliche Information)
Gruß Michael
--- Originally created by okapi on September 17th, 2009, at 11:42am
leofeyer
commented
12 years ago Ich habe gelernt, dass sich die für die TYPOlioght-Seiten einstellbare Cache-Speicherzeit nur auf den Browser-Cache bezieht.
Nein, schon auf beides :)
Der Server-Cache verringert die Serverlast, dadurch dass keine DB-Verbindung mehr benötigt wird. Der Browser-Cache verringert die Anzahl der Anfragen, die an den Server gesendet werden. Beides zusammen gibt einen erheblichen Performance-Vorteil gegenüber Systemen, die nur eine der beiden Varianten anbieten.
Eine Cache-Verfallszeit von 15 Sekunden ist ein optimaler Kompromiss und schon sehr sehr effektiv. Bei nur einer Anfrage pro Sekunde hättest Du die Serverlast dadurch schon auf ein 15tel reduziert - natürlich muss die Seite trotzdem vom Apache ausgeliefert werden, also ist es praktisch wahrscheinlich "nur" ein 10tel. Sicher ist aber, dass nur noch alle 15 Anfragen eine DB-Verbindung aufgebaut wird!
Du solltest Deine Lösung also nicht nur als faulen Kompromiss sehen. Die Cache-Zeiten auf typolight.org liegen auch nicht höher und der Effekt ist beachtlich.
--- Originally created on September 17th, 2009, at 11:55am
ghost
commented
12 years ago Danke für die Information! Darf ich dich noch fragen, was nach den 15 Sekunden mit den im Dateisystem (/system/tmp) gecachten Seiten passiert? Werden diese nach Abmeldung des FE-Users wieder dem Browser zugestellt?
--- Originally created by okapi on September 17th, 2009, at 12:14pm
leofeyer
commented
12 years ago Die Seiten werden nach Ablauf der Cache-Verfallszeit neu angefordert und dann wieder für 15 Sekunden zwischengespeichert. Während ein Benutzer angemeldet ist, ist der Cache nicht aktiv (für seine spezielle Sitzung). Sobald er sich abmeldet, wird der Cache-Header wieder gesendet.
--- Originally created on September 17th, 2009, at 12:18pm
ghost
commented
12 years ago Ich verstehe, sie werden also bei einem neuen Aufruf nach Ablauf der Cache-Zeit neu generiert. Das ist ein äussert informativer Thread zum Verständnis des TYPOlight-Caches geworden
Michael
--- Originally created by okapi on September 17th, 2009, at 12:33pm
ghost
commented
12 years ago Wirklich sehr aufschlussreich. Aber an dieser Stelle noch einmal die Frage: Wäre es nicht schöner diese beiden Mechanismen auch getrennt zu behandeln? Ich denke da an installationen bei Anbietern mit einer echt lahmen DB Anbindung (Namen brauch ich glaube ich nicht nennen). Da wäre es enorm hilfreich die Daten auf dem Server zu Cachen aber aus den bekannten Gründen eben nicht im Browser Cache vorzuhalten.
Viele Grüße
--- Originally created by MacKP on September 17th, 2009, at 01:00pm
fbender
commented
12 years ago Wie schaut's aus mit dem Feature Request, dass man TL-Cache und Browser-Cache separat einstellen kann? Überlegst du es dir, leo? Man könnte ja, um die aktuelle Einfachheit zu wahren, dieses Feature über die Einstellungen optional zuschaltbar machen, oder aber die aktuelle Handhabe beibehalten und über eine zusätzliche Checkbox die Anweisung für den TL-Cache überschreiben. Einfacher wäre aber glaube ich eine neue (unabhängige) Option. Siehe Bild für ein Beispiel.
--- Originally created on September 17th, 2009, at 01:58pm
leofeyer
commented
12 years ago Ich wäre eher für eine zusätzliche Option in den Backend-Einstellungen.
Cache Nur Server-Cache Nur Client-Cache Beides
Wie oft kommt es vor, dass man eine Seite 30 Minuten im Server-Cache behalten möchte, aber nur 15 Sekunden im Client-Cache? Das macht wenig Sinn, daher muss die tl_page nicht noch unnötig mit zusätzlichen Feldern belastet werden.
--- Originally created on September 17th, 2009, at 03:12pm
ghost
commented
12 years ago Top! Damit ist glaube ich vielen schon geholfen. Und auch langsame DB Verbindungen kann man damit dann sehr schön ausgleichen.
Vielen Dank
--- Originally created by MacKP on September 17th, 2009, at 03:14pm
fbender
commented
12 years ago Wie oft kommt es vor, dass man eine Seite 30 Minuten im Server-Cache behalten möchte, aber nur 15 Sekunden im Client-Cache? Das macht wenig Sinn, daher muss die tl_page nicht noch unnötig mit zusätzlichen Feldern belastet werden. Das ist sogar ziemlich sinnvoll! Ich ändere auf einer Seite, die keine minütlich aktualisierten Elemente enthält*, nur selten etwas. Ich möchte, das die Seite so fertig im TL-Cache bleibt (sagen wir 6h). Die Nutzer sollen jedoch, siehe Diskussion oben, die Seiten alle 15 Sekunden von der Seite neu laden. Klar habe ich dadurch zwar keinen sonderlich hohen Effekt bezüglich HTTP-Requests und Traffic, aber die DB und der Server werden doch deutlich entlastet (die Seite muss nicht jedesmal erneut gerendert werden).
Diese Lösung ist schonmal etwas, danke, ich hätte aber gerne mehr ;-). Überlegst du es dir bitte nochmal?
--- Originally created on September 17th, 2009, at 03:35pm
ghost
commented
12 years ago Ich freue mich jedenfalls auf dieses Feature, auf die Version 2.8.0
Michael
--- Originally created by okapi on September 18th, 2009, at 06:56pm
leofeyer
commented
12 years ago --- Originally completed on October 9th, 2009, at 01:01pm
Beschreibung des Fehlers an Hand eines Beispiels:
Ich habe auf der Root-Ebene vier Seiten angelegt. Die letzte, vierte, ist eine geschützte Seite. Diese wird nicht gecacht, die anderen drei schon. Eine normale Navigation ist eingebunden mit Level 0.
Als normaler User eingeloggt, sehe ich jetzt drei Menüpunkte, den der geschützten Seite erwartungsgemäß nicht.
Als zufgriffsberechtigter FE-User für die geschützte Seite eingeloggt, sehe alle vier Menüpunkte, also auch den der geschützten, vierten Seite.
Nun der Fehler: wenn jetzt irgendeine der drei (gecachten) Seiten-Links im Menü angeklickt wird, verschwindet der Menüeintrag für die geschützte Seite.
Bei Wiederholung des Seitenaufrufs oder durch Browser-Refresh, kommt der Menüeintrag der geschützten Seite wieder zum Vorschein.
Dieses Verhalten tritt auch bei der Online-Demo auf. Bei abgeschaltetem Browsercache scheint der Fehler nicht aufzutreten.
Download the attachments
--- Originally created by okapi on September 16th, 2009, at 10:57am (ID 1008)