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 different divisions. In case somebody is interested - it's warehouse management/controlling system. 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. Pitcher. В Втр, 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: > http://www.zope.org/Wikis/ZODB/ > > ZODB-Dev mailing list - ZODB-Dev@zope.org > http://mail.zope.org/mailman/listinfo/zodb-dev _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
