httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <>
Subject Re: [Patch]: Scoreboard as linked list.
Date Fri, 03 Aug 2001 05:19:09 GMT

Ryan Bloom wrote:

>My modules are walking the scoreboard on every request to gather information
>that is only stored there.  Any locking will kill the performance of those modules.
that sounds kinda ugly performance wise anyway,
just out of interest, why does you module need scoreboard info on each 

couldn't we use a rw_lock/spin lock  instead of a mutex? that wouldn't 
be as big a hit as a mutex


>On Thursday 02 August 2001 20:49, Brian Pane wrote:
>>Ryan Bloom wrote:
>>>-1.  As I have stated multiple times, if this uses a mutex to lock the
>>>list whenever something walks the scoreboard, I can't accept it.  It will
>>>kill the performance for modules that I have.
>>I'm not convinced that you actually have to lock the whole list
>>during a scoreboard traversal.  In fact, if a node's contents
>>are left intact when it's 'deleted' and put back on the free
>>list, it may even be possible to add/remove nodes without using
>>locks (assuming that only one thread can add/remove notes at a
>>time and the amount of time that a deleted node spends on the
>>free list is long enough for a scoreboard-walking reader that
>>happens to have a pointer to that node to finish reading from
>>that node before the node is reallocated).  Also, the documentation
>>that Paul posted mentions the option of using per-process or
>>per-worker locking; that might offer sufficiently small granularity,
>>depending on what specifically your modules are doing with the
>>>On Thursday 02 August 2001 19:26, Paul J. Reder wrote:
>>>>Ok, I have finally finished this version of the scoreboard redesign. The
>>>>basic idea is to implement the scoreboard as a linked list. The design,
>>>>test results, benefits, and patch are at
>>>>Please check it out and give it a try. It performs very well.
>>>>The brief performance results for this patch are:
>>>>  Current Time: Thursday, 02-Aug-2001 13:32:45 EDT
>>>>  Restart Time: Thursday, 02-Aug-2001 11:02:44 EDT
>>>>  Parent Server Generation: 0
>>>>  Server uptime: 2 hours 30 minutes
>>>>  Total accesses: 2456532 - Total Traffic: 69.3 GB
>>>>  CPU Usage: u42.52 s92.34 cu.29 cs2.35 - 1.53% CPU load
>>>>  273 requests/sec - 7.9 MB/second - 29.6 kB/request
>>>>  327 requests currently being processed, 172 idle workers
>>>>compared to the current cvs code (reported yesterday):
>>>>  Current Time: Wednesday, 01-Aug-2001 10:48:54 EDT
>>>>  Restart Time: Wednesday, 01-Aug-2001 08:09:19 EDT
>>>>  Parent Server Generation: 0
>>>>  Server uptime: 2 hours 39 minutes 35 seconds
>>>>  Total accesses: 2259384 - Total Traffic: 63.1 GB
>>>>  CPU Usage: u31.79 s96.78 cu0 cs.06 - 1.34% CPU load
>>>>  236 requests/sec - 6.8 MB/second - 29.3 kB/request
>>>>  190 requests currently being processed, 0 idle workers
>>>>There is a lot more info about the design, benefits, and test results
>>>>at that web page so rather than take up any more bandwidth, please
>>>>check it out. The patch applied cleanly to cvs head as of Thursday
>>>>at about 12:00 noon east coast time.
>>>>Also, please let me know if you have any problems getting at the page.

View raw message