Vom Querycache eines Contentportals profitieren derzeit alle Portaluser. Unter hoher Last werden so kaum noch Datenbankabfragen durchgeführt.
Der Portletcache ist laut Spezifikation userabhängig. Somit profitiert ein Benutzer nicht von anderen Benutzern die dieses Portlet vor ihm schon gesehen haben. Zusätzlich gibt es bei stark dynamischen Portalen viele Cache clears, aufgrund einer hohen Abhängigkeit zwischen den Portlets.
Ein Cache auf der mittleren Ebene der Business Logik kann hier abhilfe schaffen. Folgendes Code Snipplet zeigt anhand des Taschenrechner Beispieles des Gentics Portal.Node SDK's wie so ein Cache implementiert werden könnte.
Konzept
Dieses generische Konzept basiert auf der Erweiterung der render Methode eines Portlets. Da in der Renderphase eines Portlets üblicherweise alle Daten bekannt sind, die entscheiden wie die Respones aussieht, kann man die Abhängigkeiten ermitteln, und daraus einen Cache Key erstellen. Nach dem Rendern des Portlets kann man die Response nun im Cache ablegen, und für spätere Zugriffe direkt aus dem Cache ausliefert werden.Vorallem unter hoher Last (hunderte oder tausende parallele Benutzer) sollte die Implementierung dieses Konzept die Performance extrem steigern.
BeispielImplementierung
1. Man ersetzt die Methode doView der Klasse GenticsCalculatorModule (ein GenticsPortlet) des Taschenrechnerbespiels im Gentics Portal.Node SDK Beispielportal mit folgendem
neuen Code (ohne Gewähr) (1.7 KB).2. Man deaktiviert die DoubleKlickProtection, in dem man in der Portalkonfiguration in der general-section den Parameter portal.viewplugin.doubleclickprotection auf den Wert false setzt.
Ausprobieren
Wenn man nun den Taschenrechner bedient, erkennt man bei neuen Berechnungen die simulierte Berechnungszeit (2 Sekunden). Wenn man eine Berechnung ein zweites Mal durchführt wird das Ergebnis sofort dargestellt, weil gecached. Und das portalweit, also benutzerunabhängig.Chancen und Risken
Die Herausforderung an diesem Konzept ist es, gute und vorallem korrekte Cache Keys zu ermitteln. Personalisierte Inhaltsnavigation hängen zB meist von einem Startordner, dem aktuellen Inhalt und den Rollen des Benutzers ab. Diese Werte gilt es zu bestimmen in einen String umzuwandeln und als Cache Key zu verwenden.Dann ist man einem aberwitzig schnellem Portal - auch unter extrem hoher Last - einen Schritt näher. Vorallem Portale in denen 90% der Benutzer die selben Inhalte einsehen (Startseite, erste Navigationsebene) profitieren von diesem Konzept.
Allerdings empfiehlt es sich die Cache Zeit sehr kurz (zb 1 Minute) zu halten, da sonst zB ältere Inhalte zu lange zu sehen wären.
am 12.11.2008 von Laurin Herlt
© Gentics Software GmbH Gonzagagasse 11/25 1010 Wien Impressum AGB
