[Zope] high loads, more threads, spinning wheels

[Stefan H. Holek]

On 29. Apr 2005, at 15:34, Jim Abramson wrote:

> Can this be taken to mean that:
>
> - the practical maximum number of threads to run your single (non-ZEO)
> zope instance is {number of zodb connections in pool} else you risk
> deadlock
>

You will want to make the connection pool a bit larger than the number 
of threads you start. But see below.

> if yes, would upping the number of ZODB connections effectively raise
> the ceiling - e.g. 12 ZODB connections -> 12 threads should perform
> properly ?   Is increasing the number of ZODB cx's possible, let alone
> advisable?  (why the default of 7 - not 6 or 8?)
>

Upping the number of threads is unlikely to give you better 
performance. The only case where this could make sense is if you had 
something like a highly saturated RDBMS backend, tying up your worker 
threads.

But - Zope threads don't operate like you probably expect from knowing 
Apache and similar models. For one, they *never* will run in parallel. 
Python employs a global interpreter lock (GIL), so there will only be a 
single thread "working" at all times. What you want is to up the number 
of processes (interpreters) not the number of threads. Hence ZEO.

> More concretely, is there any good way to increase the request-handling
> capacity of a standalone instance, beyond the limits imposed by the
> defaults, without deploying ZEO?

Caching is essential. Put up a squid. And buy real hardware. Zope won't 
give you love on PC-class devices. Buy more RAM, and then some more.

And there is nothing wrong with ZEO, really, there's only advantages. I 
run it on my laptop even. On modern hardware you can easily run 2-4 ZEO 
clients per CPU.

HTH,
Stefan

--
Software Engineering is Programming when you can't. --E. W. Dijkstra