httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul J. Reder" <rede...@raleigh.ibm.com>
Subject Re: [Patch]: Scoreboard as linked list.
Date Sat, 04 Aug 2001 15:24:33 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.

Since you have not offered any details about these modules, allow me to make some
uneducated guesses and questions.

I can assume, based on the limited information, that you are collecting information
for some version of real-time information. Either to determine a single set of
statistics (i.e. average X, or total Y), or to report some individual results/problems
(i.e. snmp alerts, or real-time worker stats).

I can certainly see that if you need to walk the entire SB every time that locking
would be bad, causing all requests to be serialized by the SB lock.

But do you *really* need to walk the whole SB? What I mean is that there are only two
reasons that the information in any given worker changes: The worker processes a 
request or the worker goes away. Actually, both of these can be lumped into - the
worker experiences a status change. It seems to me that you are walking the entire
SB each time even though, at any given time from the requests perspective, only the
worker processing the current request has changed. Any changes you happen to
pick up for workers processing other requests will be incomplete until they have
arrived at their next stable state, at which time you will walk the tree as a result
of their request.

What if we set up a "state change hook" that would provide your modules a hashable
value and access to the worker. You would never need to walk the whole SB. Your
function could use the current info to update just the part of your stats related
to the worker that changed. It seems to me that something like this would provide
your module with much better performance, as well as eliminate any problems with
locking.

Of course, due to my lack of knowledge of your code, this may not make any sense,
but I'm always open to education. Enlighten me as to why walking the whole SB on each
request is required when only the worker processing the request will be updated.

My suggestion seems to reduce the processing to a single discrete event (i.e. worker
X has changed state) instead of having potentially multiple overlapping walks of
the SB happening, picking up bits and pieces of other state changes in progress. You
will never run into the case where a single worker has multiple state changes
happening simultaneously (unless your module code is really slow - which I doubt),
therefore, locking should not be an issue and serialization should never be a
concern. Access to the worker is guaranteed since the workers are in existence
(either active or on the free list) until Apache has been restarted and all
workers have quiesced (hence no state changes...)

-- 
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it.  Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein

Mime
View raw message