If you really want to know the numbers that we have played with...
Zserver threads - pool size
5 - 10
15 - 25
40 - 55
70 - 100
100 - 150
But there is no difference. We raised up these numbers according to the
comming clients, project is involving more and more workers and
In case somebody is interested - it's warehouse management/controlling
In future there will be more than 320 people working at ones. Right now
we have about half of that load.
And i want to let you know that zope based upon zodb works amost perfect
at this task, except losing connections... or forgetting to forget
connections... :) and there is no limit as i can observe at this time.
Small improvement would place zodb to a higher software level of
reliability and stabilyty in a stress site load.
Tim, I don't like very mutch the idea of resetting cache on the throwing
away connection. I've played with this before Dieter suggested to do it.
I can't describe it very clearly, cause it'has no reproducable rsults.
But i guess that some zope code, may be publisher code uses some
connection attributes after closing connection. It looked like some
attributes returned None as a result of emty cache and closed
connection, and some data from site was missing. You can try it just
with often requests to the zope management interface and small pool_size
with clearing cache on removing.
I know that they soudn't be using anything after connection close, but i
think they are... and cache removal will lead to many changes in the
existing code based on the top of zodb.
I would prefer to break circle of objects references, so that connection
could silently die not waiting for the gc expiation... :)
But it's just a hope.
В Втр, 03/01/2006 в 14:38 -0500, Tim Peters пишет:
> [Tim Peters]
> >> I'm still baffled by how you get into this state to begin with. Florent
> >> explained why earlier, and I didn't see a reply to this part:
> [Florent Guillaume]
> >>> By itself Zope never uses more than one connection per thread, and the
> >>> number of thread is usually small.
> >> You replied that you had "hundreds" rather than "thousands" of
> >> connections, but it's a still mystery here how you manage to have that
> >> many. For example, Zope defaults to using 4 ZServer threads, so do you
> >> specify a much larger zserver-threads value than the default?
> [Dieter Maurer]
> > I explained how Zope can aggregate much more connections when the maximal
> > number of worker threads exceeds the size of the connection pool.
> > Apparently, you missed this message.
> No, I saw it (and thanks), but in the absence of specifics from Pitcher
> there was no particular reason to believe it was a relevant guess. Pitcher
> said yesterday:
> At the time we used Zope-2.7.4 we had zope blocks very often and
> deny of serving, while high activity period, so to prevnt blocks we
> had set up the big pool-size and zserver threads parameters (we've
> played with different values but allways pool_size was larger number
> for about 1.5 times). It worked for a while. So...
> I still don't know what pool-size and zserver-threads _are_ set to, but it's
> clear he believes his pool-size is substantially (~1.5x) larger than his
> zserver-threads setting (in which case, no, it doesn't seem likely that he's
> got more threads than connections).
> For more information about ZODB, see the ZODB Wiki:
> ZODB-Dev mailing list - ZODB-Dev@zope.org
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org