[ZODB-Dev] Re: Connection pool makes no sense

[Юдыцкий Игорь Владисла]

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 at zope.org
> http://mail.zope.org/mailman/listinfo/zodb-dev