httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject Thoughts on implementing mod_status in MPM...
Date Thu, 05 Aug 1999 22:32:09 GMT
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