Caching: Brauche mal eine grundlegende Einweisung
Eingetragen von maen (547)am 01.05.2014 - 14:20 Uhr in
Wie erkläre ich es am Besten:
Bis dato habe ich nur Sites entwickelt, in denen wenige für viele Inhalte gebaut haben, also Artikel etc. erstellt haben, die dann einfach zu chachen waren. Bedeutet die wurden in die caching Tabelle gelegt, von da abgeholt und dargestellt.
Jetzt ist es so, dass ich mittels organic groups eine Seite gebaut habe, bei der die Inhalte pro Seite userabhängig sind. D.h. fast jede Funktion die da ausgeführt wird enthät ein global $user, um dann davon ausgehend Daten aus der MYSQL abzugreifen.
Und deshalb sitze ich jetzt vor dem Performance Problem.
Ich habe mir jetzt folgendes durchgelesen:
http://www.lullabot.com/blog/article/beginners-guide-caching-data-drupal-7
und
https://drupal.org/node/145279
Darin wird zwar beschrieben, wie cache_set und cache_get anzuwenden sind, aber ob das überhaupt Sinn macht bei nutzerbezogenen Daten und Funktionen erschließt sich mir nicht.
Dann noch das Thema varnish, memcache und mongoDB. Gerade bei mongoDB lese ich die interessantesten Darstellungen.
Ich habe da gelesen dass User reuhmütig wieder zu MYSQL zurück sind, dann von welchen die es nur empfehlen können, (das waren dann aber in der Regel die die auch ihren diesbezüglichen Service verkaufen wollten). Außerdem habe ich in der DB sehr viele fields. Für den wichtigsten Content Typen über 30.
Dann habe ich gerade bei varnish gelesen, dass es da viele Probleme gab/gibt.
tldr;
Extrem viele Nutzerbezogene Daten. Wie cached man richtig? Was empfehlt Ihr?
Danke vorab,
maen
- Anmelden oder Registrieren um Kommentare zu schreiben
Hallo maen, ich kann dir zwar
am 01.05.2014 - 15:56 Uhr
Hallo maen,
ich kann dir zwar nicht zu etwas bestimmten raten, da ich auch mit dem Thema gerade anfange, hier aber noch ein interessanter Artikel:
http://www.wunderkraut.com/blog/caching-with-varnish-drupal-7-and-cache-...
Mein Hoster arbeitet mit Varnish https://www.varnish-cache.org/ für grosse Shopsysteme mit zig tausend Artikeln und die erzielen damit sehr gute Erfolge.
Ich werde wahrscheinlich denen die Konfiguration überlassen für eine Installation von mir, da die sich mit dem Drupal Modul auseinandersetzen und den Server dann darauf abstimmen...
Das Thema ist so komplex.. falls du dich für eine Variante entscheidest und zufrieden bist, würde mich ein Feedback sehr interessieren.
Grüße Jenna
Danke für den Artikel,
am 01.05.2014 - 16:50 Uhr
den kannte ich noch nicht. Aber Varnish bezieht sich auf das Caching von Seiten. Das Einsatzgebiet ist dann relevant wenn ich viele Artikel für nicht authentifizierte Nutzer habe. Wenn ich allerdings dynamische Inhalte in Abhängigkeit des jeweiligen individuellen Betrachters habe bringt mir Varnish meiner Meinung nach wenig.
Aber trotzdem Danke!
Die erste Frage, die sich für
am 02.05.2014 - 11:18 Uhr
Die erste Frage, die sich für mich da stellt, ist, wie die Seiten aufgebaut werden:
- sind das lauter Views? Hier kannst Du die Views-Ergebnisse zwischenspeichern, wenn Du die User-Id des aktuell angemeldeten Nutzers als Kontextfilter festlegst, geht das auch per User
- oder sind das lauter Panels? Auch Panels bietet ein Caching
- was sind das überhaupt für Inhalte? Müsste auf einer Seite mehrere Blöcke getrennt voneinander gecacht werden, weil sich die Inhalte unterschiedlich oft aktualisieren, oder könnte man damit leben, eine ganze Seite je User zu cachen.
Und überhaupt: ist Caching wirklich die Lösung? Ich meine, wenn ein Nutzer Seite A ein Mal besucht, sieht er erstmal die ungecachte Seite. Dann klickt er woanders hin, sieht wieder erst die ungecachte Seite - kommt er dann wieder zurück auf Seite A? Weil erst dann würde er ja die gecachten Daten sehen und es gäbe erst dann tatsächlich irgendeinen Performance-Gewinn.
Grundsätzlich ist das Seiten-Caching bei angemeldeten Nutzern bei Drupal ja aus gutem Grund deaktiviert - u.U. macht das Caching nämlich überhaupt keinen Sinn und führt ins Gegenteil. Daher fänd ich es außerdem wichtig mal zu schauen, ob Du nicht auf ein leistungsstärkeres Hosting-Paket aktualisierst - vielleicht bringt das doch mehr, als jetzt eine komplizierte Caching-Strategie für angemeldete Nutze aufzubauen?!
Dann step by step: - Es sind
am 02.05.2014 - 11:42 Uhr
Dann step by step:
- Es sind keine views, sondern selbst geschriebene Blöcke/Funktionen. Bis dato alle mit Drupal_No_Cache ausgewiesen.
- Keine Panels. Alles von Hand geschrieben, weil die Abfragen alle aufgrund der hohen individuellen Bedürfnisse mit views nicht funktionieren würden.
- Auf einer Seite müssen per OG und per user individuelle verschiedenen Blöcke gecacht werden. Weil dort Handlungen vom User ausgeführt werden, und somit hooks Inhalt und Lebensdauer der Blöcke teileweise bestimmen.
Nein, man kann nicht damit leben ganze Seiten zu cachen, dann wäre Varnish ja optimal.
Der Performance Gewinn ist schon deshalb gegeben, ohne es jetzt überprüft zu haben, weil ich teileweise Blöcke per organic group speichern will, teilweise auch überhaupt nicht. Werden sehen.
Das mit dem Hostingpaket liegt nicht in meiner Hand.
Danke für Deinen Beitrag. Vielleicht kommt in diesem thread ja auch für spätere Entwicklungen was bei raus. Ich lese ja in jedem 2.englischen Performance thread die Beschwerde, das drupal zu langsam und aufgebläht wäre. Habe mal mit einem befreundeten Java Entwickler gesprochen, der meinte evtl. wäre es ab einer bestimmten Größenordnung von Vorteil die DB ganz in den Cache zu legen.
Jetzt habe ich in einem anderen thread gelesen dass node_load() und user_load() das Objekt pro Seite cachen würden.
Dann gibt es noch die DRUPAL_CACHE_PER_USER Konstante. Die wäre bei hooks aber auch sinnlos.
Na ja, ich bleibe mal am Ball.