Plone Performance Tuning

Apache, Lighttpd, nginx, Cherokee
User avatar
daemotron
Administrator
Administrator
Posts: 2635
Joined: 2004-01-21 17:44

Plone Performance Tuning

Post by daemotron » 2007-05-14 13:43

Hallo,

meine Plone-basierte Website fühlt sich etwas "träge" an (nahezu Standard-Layout). Um das Rendering im Browser ausschließen zu können und das Bauchgefühl mal mit Fakten zu untermauern, habe ich die Site gestern mit httperf unter die Lupe genommen und mit Entsetzen festgestellt, dass ich so zwischen 1,5 und 3 Requests pro Sekunde hinbekomme. Auf der Seite ist nicht allzu viel los, aber der gefühlt langsame Seitenaufbau nervt (bei ca. 300 - 500 ms pro Request, mehreren Stylesheets und Layout-Grafiken etc. summiert sich das ganz schön).

beim googlen nach Performance Tuning für Plone und Zope bin ich bisher auf zwei Hauptthemen gestoßen: vorgeschalteter Caching Proxy und ZEO. Ehrlich gesagt halte ich beide für mit Kanonen auf Spatzen geschossen, aber wenn's nicht anders geht...

Wenn Cache Proxy, worauf würdet ihr setzen? Squid? Apache? oder etwas völlig anderes? Bei Lighty macht mir die unvollständige Dokumentation von mod_proxy und mod_mem_cache noch zu schaffen...

Wie steht's mit ZEO? Verhindert das globale Interpreterlock von Python wirklich, dass innerhalb einer Prozessgruppe immer nur jeweils ein Thread laufen kann, auch auf einem SMP-System?

Und zu guter letzt: Gibt es noch andere Möglichkeiten als die genannten? Wie habt ihre eure Zope/Plone-Sites beschleunigt?

juergen
Posts: 133
Joined: 2004-03-30 14:44

Re: Plone Performance Tuning

Post by juergen » 2007-05-14 22:29

jfreund wrote:Hallo,

meine Plone-basierte Website fühlt sich etwas "träge" an (nahezu Standard-Layout). Um das Rendering im Browser ausschließen zu können und das Bauchgefühl mal mit Fakten zu untermauern, habe ich die Site gestern mit httperf unter die Lupe genommen und mit Entsetzen festgestellt, dass ich so zwischen 1,5 und 3 Requests pro Sekunde hinbekomme. Auf der Seite ist nicht allzu viel los, aber der gefühlt langsame Seitenaufbau nervt (bei ca. 300 - 500 ms pro Request, mehreren Stylesheets und Layout-Grafiken etc. summiert sich das ganz schön).
Deine Plone/Zope-Instanz läuft nicht im Debug-Mode?
jfreund wrote: beim googlen nach Performance Tuning für Plone und Zope bin ich bisher auf zwei Hauptthemen gestoßen: vorgeschalteter Caching Proxy und ZEO. Ehrlich gesagt halte ich beide für mit Kanonen auf Spatzen geschossen, aber wenn's nicht anders geht...

Wenn Cache Proxy, worauf würdet ihr setzen? Squid? Apache? oder etwas völlig anderes? Bei Lighty macht mir die unvollständige Dokumentation von mod_proxy und mod_mem_cache noch zu schaffen...

Wie steht's mit ZEO? Verhindert das globale Interpreterlock von Python wirklich, dass innerhalb einer Prozessgruppe immer nur jeweils ein Thread laufen kann, auch auf einem SMP-System?
Das ist korrekt, ein Zope-Request hat einen globalen Lock auf die ZODB. Abhilfe bringt nur die Konfiguration von ZEO: Das ist nicht wirklich schwierig und du kannst mehrere Frontend-Server betreiben um die Performance weiter zu steigern. Ansonsten ist die Kombination Squid/Zope weit verbreitet.

Jürgen

User avatar
daemotron
Administrator
Administrator
Posts: 2635
Joined: 2004-01-21 17:44

Re: Plone Performance Tuning

Post by daemotron » 2007-08-08 23:04

juergen wrote:Deine Plone/Zope-Instanz läuft nicht im Debug-Mode?
Nein, ganz normal als Daemon per zopectl gestartet...

Nachdem ich endlich wieder mal ein bisschen Zeit hatte, mich damit zu beschäftigen, kann ich jetzt folgendes berichten: Die Umstellung auf ZEO ist sehr zu empfehlen. Selbst bei nur einer Zope-Instanz macht sich das bereits bemerkbar (allerdings leider auch im RAM-Konsum). Der Einsatz mehrer Zope-Instanzen mit demselben ZEO-Backend bringt natürlich auch etwas, aber die Steigerung ist nicht so enorm. Knackpunkt ist da auch eine vernünftige Balance-Strategie des Reverse Proxies...

Unterm Strich bin ich jetzt mit 4 Instanzen und Lighty davor (Balance-Modus "fair") auf ca 130ms pro Request runtergekommen; das ist schon mal eine ganz passable Steigerung. Für den regulären Betrieb werde ich wohl wieder auf Hash als Balance-Mode zurückgreifen und noch ein bisschen an der Caching-Policy der einzelnen Zope-Instanzen schrauben (für den Benchmark wäre Hash ziemlich sinnfrei gewesen, da ja immer dieselbe URI aufgerufen wird und bei "hash" dann auch immer derselbe Backend-Host vom Proxy bemüht würde).