Re: Mehr Speed?

Hi!

Am Montag, den 30.03.2009, 10:07 +0200 schrieb Peter Zechmeister:
> Hallo,
> 
> (wieder mal) ein paar Fragen zu Caches, Ram, Threads...
> 
> Wir haben ZEO und jeweils 4 Worker-Threads und die Anzahl der Objekte im
> Cache ist sehr hoch eingestellt, dass die Clients durchaus 1-2 Gig Ram
> brauchen dürfen.

Ich habe sehr gute Erfahrung mit der Reduktion auf max 2 Threads
gemacht. Weniger gegenseitige Blockade führen zu besserer Performance.

> Soweit ich das verstehe, ist der Flaschenhals ja, dass Objekte, die
> nicht im Object(Ram)-Cache liegen, von der HD aus einem temporären
> Datenbankfile geholt werden müssen.

Der ZEO-client fährt 2 Strategien: zum einen den RAM-Cache, der über die
Objektanzahl limitiert wird, zum anderen den Disk-Cache, der über einen
Byte-Wert limitiert wird. Die gesamte Strategie ist mehr als fragwürdig
und entspricht definitiv nicht dem, was ich unter modernem
Cache-Management verstehe. 

> Was wäre nun, wenn ich dieses File nicht auf die HD, sondern in eine
> Ramdisk legen würde? Könnte man dann auf die großen Object-Caches
> verzichten?

Meiner Meinung nach sinnlos, s.u.

> Der Nebeneffekt wäre, da die Object-Caches ja redundant Ram fressen (pro
> Worker einer), dass man viel mehr Ram frei hätte, bzw. das temporäre
> File durchaus groß sein dürfte.

Soweit ich das verstanden habe, cached nicht jeder Worker-Thread
separat. Im Code angeschaut habe ich den Teil noch nicht (wir haben max
1-2 Worker-Threads, da ist das relativ nebensächlich).

> 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?

Bingo. Und deswegen macht die RAM-Disk wenig Sinn. Nutze den RAM lieber
geschickter aus.

> Oder ist der Flaschenhals eher der Zugriff auf die Objekte in der DB und
> nicht der Zugriff auf die HD?

Wenn die DB auf einer anderen Maschine liegt ist das der Flaschenhals,
sonst weniger (und man kann sich einen großen Diskcache sparen). Meine
Tests haben ergeben, dass primär das entpickeln der Objekte Performance
frisst. Alles was aus dem Disk-Cache oder von der DB geladen werden muss
wird entpickelt. Im RAM-Cache leben schon konkrete Objekte. Daher ist
die Maxime diesen möglichst gut zu nutzen. 

Die Strategie ist aber auch von Anwendung zu Anwendung völlig
unterschiedlich. Eine öffentliche Webseite ohne viele Logins muss man
völlig anders aufziehen wie ein Intranet. 

Ein weiteres Kriterium ist dann noch wie man die Caches füllt, wo man
zusätzlich noch mit memcached viel Zeit sparen kann usw. Grade bei
Intranets kann man da sehr viel Zeit sparen. Aber es gibt nicht das
perfekte vorgefertigte Rezept. An der Stelle kommt man um
applikationsspezifisches Profiling nicht herum. Zudem stellt in dem
Zusammenhang sich die Frage was günstiger ist: Arbeitszeit investieren
oder eine Maschine dazustellen...

beste gruesse Jens
-- 
Jens Klein
Software Architect
Managing Director, General Partner
+43 512 890077

BlueDynamics Alliance        WEB APPLICATIONS,  ZOPE,  PLONE, HOSTING
Klein & Partner KEG          production: concept, development, design
http://bluedynamics.com      consulting: analysis, coaching, training
http://zoplo.com             management: projects, process, community



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