apr-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 40348] New: - apr_reslist ttl setting not enough to regulate pool size
Date Tue, 29 Aug 2006 16:44:53 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=40348>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40348

           Summary: apr_reslist ttl setting not enough to regulate pool size
           Product: APR
           Version: 1.2.7
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: APR-util
        AssignedTo: bugs@apr.apache.org
        ReportedBy: cboitel@lfdj.com


Say you use apr_reslist_xxx function set and configure a pool of connections 
to a back-end system: hmax set to 100, smax set to 25 and ttl set to 300 
(seconds).

Now, imagine the following usual scenario:
1/ your normal load is such that no more than 10 connections are required at a 
time
2/ once a day, you experiment peak loads that forces the pool to grow to 50 
connections for say an hour

One would expect the pool to shrink back to 25 connections (smax setting) when 
load has returned back to normal. It will not.

This is due to the way the pool is used: acquire will pop a connection from 
the list (first entry) and release will push connection back to the list 
(added to the tail).
=> if your load is such that you use all connections in the pool within ttl 
setting, then pool will never shrink
=> pool will shring only if you experiment no load for the ttl setting (and we 
usually hope to have far more)

If release was adding the connection back to the head of the pool, then pool 
size regulation can occur (reslit_maint function will have to be updated to 
start looking at entries at the tail of the ring).
=> this way, if no more than 10 connections are used at a time, then only the 
first 10 connections in the pool will be used and the maintenance routine will 
clean the all but first 25 connections.

By the way, i would actually change the reslit management such that:
- ttl setting would mean "maximum time a resource may stay in the pool" 
(closer to time to live meaning)
- inactivity setting would mean "release resource if not used with the timeout 
specified

I would like to contribute a patch for this but don't know how to handle the 
change in the API if ttl/inactivity are to be handled. Would like your 
suggestions on this. Mine follows:
- keep the current apr_reslist_create API as is but make the original ttl 
setting to match new "inactivy" setting (this is probably what users of the 
API have though of it)
- provide an additional function call to set the ttl setting if needed by 
someone

This would then ensure Apache httpd mod_dbd and mod_proxy (which uses reslist) 
do provide a load adaptive service.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Mime
View raw message