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
_______________________________________________
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
