quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory (Grisha) Trubetskoy" <gri...@apache.org>
Subject Re: Session adventures
Date Thu, 31 Jul 2003 02:35:43 GMT

On Wed, 30 Jul 2003, Greg Stein wrote:

> [snip]
>
> The mapping provides a way to figure out which lock (from the pool) is being
> used to arbitrate requests associated with a session. If too many
> session-based-requests occur all at the same time, then that overflow will
> all be gated by the single overflow lock. Presumably, the admin would set
> the capacity properly, and watch for the log messages ("oh no! using the
> overflow lock!").

It always helps the creative process to read someone's comments
(especially Greg's) :-)

It just occured to me that there only needs to be a fixed number of locks,
at least as many locks as there are (maximum) working threads/processes.
The idea is balancing the likelyhood of waiting for the next available
process/thread versus waiting for the session lock.

E.g. if we have 10 processes serving the requests and a zillion sessions,
mapping a session to one of the 10 locks, e.g.

	lock_id = hash(sess_id) % 10

should be enough provided that lock_id's are evenly distributed.  Since
the distribution isn't ever even, there is going to be some collisions
(meaning sessions waiting on each other needlessly because their lock_id's
coincide).

Increasing the number of available locks decreases the probability for
collisions, but also consumes resources and at some point stops yielding
any significant benefit.

The question is what is the optimal ratio of available locks to MaxClients
(here is a thesis idea for someone?).

Grisha

Mime
View raw message