httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: [Patch]: Scoreboard as linked list.
Date Fri, 03 Aug 2001 05:49:59 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

There are two things impacting performance in this patch. The first is the overhead of
following pointers.  If you do that each request, it can add up if you have large numbers
of concurrent clients. I don't have a feel for the overhead relative to the rest of the
server though. The additional overhead of running 10,000 pointer may be noise in the
server. Or maybe not.

The second performance issue is lock contention. Acquiring a lock with no contention is
fast. If the lock has contention, the performance goes to hell fast. So the suggestion of
using a rw_lock (spin on multi cpu systems) sounds just right since accesses during normal
HTTP requests can just acquire the reader lock.

According to Paul's testing, his patch tends to manage the processes a bit better. At any
point in time, he has fewer processes active. Need to think about this some to determine
why that is. If the observation holds up, this is a peformance mark in favor of Paul's
patch as fewer processes means less memory and that's goodness.

Paul's patch also lets us eliminate HARD_THREAD_LIMIT and HARD_SERVER_LIMIT which is cool
IMO. It also lets us not allocate scoreboard for mod_status if mod_status is not loaded
(not implemented yet, but the design enables it).

Benchmarking will tell us what we need to know on the performance front.

Bill


Mime
View raw message