Yesterday I made a Zope 2 branch named chrism-zserver-connection-policies-branch. The benefits that result from the changes are that you can "reserve" a thread pool for a particular set of ZServer servers, and that you can specify alternate ZODB "connection policies" on a per-server basis. This will allow sites which are having resource exhaustion problems (e.g. running out of threads, running out of database connections) to continue to be accessible via servers running on "special" ports for debugging and maintenance purposes. I'd like to merge this into the trunk at some point, but I'd like some feedback first. -- Chris McDonough <chrism@zope.com> Zope Corporation
Chris McDonough wrote:
Yesterday I made a Zope 2 branch named chrism-zserver-connection-policies-branch.
The benefits that result from the changes are that you can "reserve" a thread pool for a particular set of ZServer servers, and that you can specify alternate ZODB "connection policies" on a per-server basis.
This will allow sites which are having resource exhaustion problems (e.g. running out of threads, running out of database connections) to continue to be accessible via servers running on "special" ports for debugging and maintenance purposes.
I'd like to merge this into the trunk at some point, but I'd like some feedback first.
Forgive me, but I don't see the motivation: a database connection represents a large chunk of RAM. Won't the new policies just cause overloaded sites to also run out of RAM? Shane
Forgive me, but I don't see the motivation: a database connection represents a large chunk of RAM. Won't the new policies just cause overloaded sites to also run out of RAM?
No. Well, at least one implementation won't. ;-) We don't reserve a pool of database connections for the special servers. The connection policy can use a temporary connection, which AFAIK does not keep a ZODB cache. But you're right in the sense that this won't help RAM-bound applications; that's what AutoLance is for. It will help debug sites where there's a database connection leak or sites where all public threads are tied up waiting for a database connection (if only to be able to restart it via the mgmt interface). - C
Chris McDonough wrote:
Forgive me, but I don't see the motivation: a database connection represents a large chunk of RAM. Won't the new policies just cause overloaded sites to also run out of RAM?
No. Well, at least one implementation won't. ;-) We don't reserve a pool of database connections for the special servers. The connection policy can use a temporary connection, which AFAIK does not keep a ZODB cache.
But you're right in the sense that this won't help RAM-bound applications; that's what AutoLance is for. It will help debug sites where there's a database connection leak or sites where all public threads are tied up waiting for a database connection (if only to be able to restart it via the mgmt interface).
Ah! Ok, so it's meant for admin-only access. That's a fine idea. Shane
participants (2)
-
Chris McDonough -
Shane Hathaway