httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: Thoughts on implementing mod_status in MPM...
Date Thu, 05 Aug 1999 23:26:35 GMT
As long as you're not requiring all MPMs to do this with shared memory... 
I'd really like to leave the stage open for an MPM to do it in whatever
way makes sense for their platform.  Which is why I'm advocating
get_first/get_next for mod_status. 

Remember also, that this is mod_status, and 1 second old data is perfectly
fine.  So it could just be that the processes copy their scoreboards up to
a central process when asked... and the mod_status requests for the next
second are satisfied from that central process. 

I think my main concern with the multiprotocol stuff is that it gets us
into the realm of variable length data... which makes all of this hard.
Unless we just decide that there are 80, or 132, or 160 bytes to play with
per connection and let each protocol format things in whatever way they

It's a tough problem isn't it? 

It's worthwhile studying how "ps" works in various unixes... since it's
roughly an equivalent action.


On Thu, 5 Aug 1999, Manoj Kasichainula wrote:

> In this note, I'm not worried about getting the API right or
> multiprotocol issues, this is orthogonal to that.
> If we don't use shared memory to keep the per-connection stats, then
> we need a way for a child to grab these stats from all of the other
> children. Without shared memory IPC, we're left with pipes. So, we'd
> either need a shared pipe, which would work sort of like a hardware
> bus, or n^2 pipes (blecch), or a coordinator process that collects the
> data from every process.
> With a shared pipe, we basically have to work out a bus protocol, make
> sure all data sent on the pipe was smaller than PIPE_BUF, etc., so I'd
> lean towards having a coordinator process, which collects data from
> all the children and passes it to the child running the mod_status
> request. No matter what pipe system we use, we'd have to make sure
> that there's always a thread available in every child really soon to
> respond to requests for status info.
> I'm leaning, though, towards putting back shared memory. It'd work a
> little differently, though. Unlike in 1.3, this shared memory would
> only be used for the mod_status data, and not at all for actually
> managing the worker pool (at least for MPMs like Dexter), so it can be
> shut off completely when mod_status isn't used. We'd make sure that
> each process is responsible for its own hunk of shared memory, and
> that no process will touch another's hunk except when collecting
> status info. We'd also try to align the hunks on cache-line boundaries
> to prevent cache thrashing. How large can cache lines get these days?
> The only problem I see is kernel threads, but they could thrash the
> cache lines on an MP system no matter what scheme we're using.
> -- 
> Manoj Kasichainula -
> IBM, Apache Development

View raw message