Re: Mehr Speed?

Am Montag, den 30.03.2009, 10:41 +0200 schrieb Andreas Gabriel:
> Hallo Peter,
> 
> Peter Zechmeister schrieb:
> > Was mich an der Idee aber irritiert ist, dass Linux ja eine sehr gute
> > Ram-Caching-Strategie fährt, und dieses temporäre DB-File ja
> > möglicherweise sowieso als ganzes im Ram liegt. Ist das so?
> 
> 
> ich beschäftige mich derzeit auch intensiv mit diesem Thema. Du hast
> recht, das File-Caching funktioniert unter Linux sehr gut. Normalerweise
> sollte bei ausreichendem RAM das temporäre Datenbankfile (hast Du
> persitenten Cache aktiviert?) im Filesystem-Cache liegen. Wenn Du
> mittels "top" die Last des Systems analysierst, hast Du da hohe Werte
> für "sy" (System CPU time) oder "wa" (iowait)? Wenn nein, dann wird Dir
> der RAM-Cache auch nicht weiterhelfen.
Ok. Das muss ich mir noch genauer ansehen.
> 
> Wieviel Objekte hast Du bereits im portal_catalog indiziert? Wenn die
> Zahl größer ist als Deine ZODB cache-size, dann kickt Dir die Suche
> zwischen- gespeicherte Content-Objekte aus dem ZODB-Cache, die während
> eines Requests unnötigerweise wieder aus der ZODB (oder temporären
> Datenbankfile) gelesen werden muss. Du solltest den portal_catalog
> in eine separate Data.fs auslagern, damit Du diesen Konflikt umgehen
> kannst und getrennt die cache-size pro Data.fs konfigurieren/optimieren
> kannst.
Hätte noch schreiben sollen, dass wir _nicht_ Plone verwenden. Also auch
keinen portal_catalog.
Aber das mit dem Umkrempeln des Object-Caches kenne ich aus ähnlichen
Gründen :-(
> 
> Des Weiteren wird bei einer großen Anzahl von Objekten (>100k) auch
> die Suche des Katalogs langsamer. Ein einzelner Request in Plone
> löst mindestens 10 mal eine Katalog-Suche aus, d.h. wenn pro Suche
> 50ms mehr Zeit verbraten wird, sind das schon insgesamt eine halbe
> Sekunde Verzögerung. Die Suchstrategie des Katalogs ist leider nicht
> sonderlich ausgereift und wurde anscheinend nur bei kleiner Anzahl
> von indizierten Objekten getestet. Wir verwenden bei uns eine
> abgewandelte Version des Produkts "experimental.catalogqueryplan"
> und konnten durchschnittlich 400-500ms an Zeit pro Request sparen.

Dann ist ja Plone noch schlimmer als das ZMS - hihi! (SCNR)
> 
> Schöne Grüße
> Andreas

Grü
PeterZ



_______________________________________________
zope mailing list
[email protected]
https://mail.dzug.org/mailman/listinfo/zope