Suresh V wrote at 2006-12-22 03:02 +0530:
... We hiked it up to 60K per thread because we have lots of memory and wanted to make Zope perform better. Is there a disadvantage to this?
Not, if you have enough RAM. Note that each connection has its own cache and that you control the cache size only by the the number of objects it may contain and not by the size of these objects. In a standard Zope setup, you cache capacity of 60 K means that up to 240 k objects can be cached. If you are using lots of "File" objects, then the "File" objects are split in 64 kB chunks. If your cache happens to be filled with such chunks, then you need about 15 GB just for ZODB caching purposes.
When the ZODB reported that it has read some number of objects, it is very likely that it did indeed.
But even under very little site activity, it seems to be loading a lots of objects. Is this normal?
It is quite easy to get the persistency design wrong. To analyse such bad design, I have instrumented our Zope copy to log information about the communication between a ZEO client (e.g. Zope) and the ZEO server). I attach the instrumented module. It is likely that you will not be able to replace the module in your Zope implementation but you can get a feeling how to approach such an instrumentation. Watch out for "_doLOG". -- Dieter