httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@cnet.com>
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 
request.

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

..Ian

>
>Ryan
>
>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
>>scoreboard.
>>--Brian
>>
>>>Ryan
>>>
>>>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 http://24.25.12.102
>>>>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.
>>>>
>>>>Thanks.
>>>>
>




Mime
View raw message