Thanks for the helpful replies; I was also curious: assuming that one has a
cache of a certain size, is there a way to inspect it (ie: to see how
full/empty it is, etc..) so one can tell how effective it is at runtime. It
would beat repeatedly running  benchmarks while varying the cache size.

On Wed, Dec 16, 2009 at 7:57 PM, Andreas Jung <> wrote:

> Hash: SHA1
> schrieb Roy Mathew:
> > Folks, I am looking for some configuration advice.
> >
> > I am running a zope3 application that uses the ZODB. I expect a
> > peak load of a 100 concurrent users, and am on a *quad* core Intel
> > Xeon Linux box. Am I better off running 2 or 3 ZEO clients talking
> > to the app-server (I am assuming that the OS will load balance so
> > that all processors are utilized well). Or should I not use ZEO at
> > all, and simply assign a large cache, a large connection pool and
> > lots of threads to a single process. I am sure that this is an
> > issue many of you have had to contend with. I would appreciate some
> > rough idea of what the numbers should be for each of the 2
> > scenarios I outline.
> >
> The number of worker threads (and clients) basically depends on how much
> concurrent requests you have. Four worker threads can deal with 100
> requests/second
> when each request can be processed fast. Long running requests will
> block other
> you must measure how long a request takes in average..then
> you can do your own calculations. The cache size depends on various
> factors..
> you have to check the ZODB activity in order to perform fine-tuning.
> There is neither a golden bullet nor a recipe for the perfect
> setup...start with
> a common setup of two clients or so and see how far you can go...then
> adjust
> your parameters over time.
> - -aj
> Version: GnuPG v1.4.10 (Darwin)
> Comment: Using GnuPG with Mozilla -
> iEYEARECAAYFAkso7jgACgkQCJIWIbr9KYxJuACgnSBYveX6o5s6405R4Q+U9i5M
> wg4AnjjM0wuytuDaWF0GEs5yF/DbPU+C
> =tzFb

Zope3-users mailing list

Reply via email to