Re: Mehr Speed?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 30, 2009, at 10:30 , Jens W. Klein wrote:

>> 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).

Vorsicht Missverständnis, hier werden zwei Dinge durcheinander  
geworfen. Auf der einen Seite gibt es worker threads, in der  
Normalkonfiguration 4. Auf der anderen Seite gibt es einen Pool von  
Datenbankverbindungen, in der Normalkonfiguration 7. Wenn ein worker  
thread Zugang zur ZODB braucht, wird eine Datenbankverbindung aus dem  
Pool genommen. Es sind diese Datenbankverbingen, die mit ihrer  
internen Cache die RAM-basierte ZODB Cache darstellen. Und zwar jede  
Verbindung mit eigener unabhängiger Cache.

Im Normalbetrieb sieht es oft so aus, als wäre das Verhältnis von  
worker thread zu genutzter Datenbankverbindung immer 1:1, woher wohl  
auch das Missverständnis kommt, dass worker threads selber das Caching  
machen. Das Reduzieren der worker threads per Konfiguration führt auch  
dazu, dass im laufenden Betrieb eben weniger Datenbankverbindungen  
genutzt werden, und somit wieder der Eindruck entsteht, die worker  
threads machen Caching.

Allgemein gesehen gibt es keine Idealkonfiguration für alle  
Situationen. Viele Leute behaupten, die Reduzierung der worker threads  
sei die Lösung aller Probleme, das ist aber Unsinn. Es kommt immer  
darauf an, was genau die Anwendung machen soll. Anwendungen, die wenig  
"teure" Arbeit zu verrichten haben und viel Daten aus der Datenbank  
lesen, sind mit weniger threads (und weniger Datenbankverbindungen)  
vielleicht gut bedient. Anders sieht es aus, wenn eine Anwendung wenig  
Daten aus der ZODB liest, sondern vielleicht viel aus einer  
relationalen Datenbank. Solche Anwendungen können von *mehr* worker  
threads und Datenbankverbindungen profitieren. Die einzig geeignete  
Massnahme, um die eigene ideale Konfiguration zu finden, ist  
vernünftiges und realitätsnahes Testen der Anwendung (load testing)  
mit verschiedenen Konfigurationsszenarien. Auch das Beobachten der  
Anwendung während der Laufzeit und eventuelle Anpassen der Parameter  
ist sinnvoll.

jens


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAknQnEMACgkQRAx5nvEhZLK8XQCfRZ+Mt161fTOiZ+be6s2YdIx5
fDAAnisPjuu95s41lH0xkjKyM0Z/PmLs
=vkyo
-----END PGP SIGNATURE-----


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