>
> Bill,
>
> I will finish my code.
If you spend the time to write it, I will look at it.
> It will
> require locking anytime somebody wants to walk the scoreboard, which means
> that potentially the scoreboard will be run once a request. Think
> mod_status and/or mod_snmp.
I don't completely understand you comment, but you are quite right that anytime the
scoreboard needs to be walked, locking will be required. The scoreboard will -not-
need to
be walked except in these relatively rare cases:
1. During a graceful restart (manipulates elements in the scoreboard)
2. During MaxRequestPerChild triggered child shutdown (manipulates elements in the
scoreboard)
3. Processing a mod_status request (walks the scoreboard)
4. Processing an SNMP request (walks the scoreboard)
Requests that do not require a scoreboard walk or adding/deleting entries from the
scoreboard (which is 99.999% or more of all requests; all requests except the ones
above)
will not require locking at all. Let me restate this... mainline requests will NOT be
required to make any lock calls at all. Ever. Mainline requests can be served and
their
status tracked even when the scoreboard is locked, so this design does not suffer -any-
performance penalties in the mainline case caused by locking.
The only reason we have locking at all is to prevent the 4 cases listed above from
colliding with each other. Even in the 4 cases above, the lock contention will be
minimal
and the performance degradation minimal and perhaps not even measureable.
A few other benefits to Pauls design:
1. Eliminates the requirement for compiled in HARD_SERVER_LIMIT or HARD_THREAD_LIMIT.
2. You don't need to allocate child score if you don't care about mod_status (but it
can
be added during a restart)
3. If you choose to not enable mod_status, you will likely see a nice performance
boost on
multi CPU machines because we are not invalidating a CPUs cache each time we touch a
worker score entry (which is on every request).
4. Does not require any changes to the MPM. Each MPM can start threads according to
its'
ThreadsPerChild setting w/o needing to pay attention to the scoreboard (I believe your
design required child processes to wait for worker score slots to become available
before
it can start threads. This is imposing too much unnecessary work on the MPM.).
Bill
