httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: [PATCH] tracking active request phase
Date Sun, 06 Mar 2005 13:41:48 GMT
On Mon, 28 Feb 2005 11:24:20 -0500, Geoffrey Young
<> wrote:
> Jeff Trawick wrote:
> > On Mon, 28 Feb 2005 08:39:06 -0600, William A. Rowe, Jr.
> > <> wrote:
> >
> >>Wow :)  That would be extraordinarily useful.  Any hope the scheme
> >>would be extensible, so a module such as cgi or rewrite could show
> >>more specific Phases?
> >
> >
> > I'm leaning towards having completely accurate info maintained by the
> > core, and arbitrary modules would need to use a separate mechanism to
> > provide more info.
> on a somewhat related note, I started down a different-but-similar-enough
> path some time ago:
> while the idea fizzled from lack of interest/review, the idea I had was to
> eventually rewrite mod_info so that it used a generic mechanism like the one
>  in the patch (albeit with more API methods, and so on).  it seems that the
> proper hook-level API could accomplish both what I wanted to do as well as
> what jeff and bill would like to see.  and that would be great :)
> so, in case it is of help with jeff's immediate itch, there it is.  if not,
> that's ok too :)

Thanks for posting that.  There is plenty of room here to make the
several vocal parties happy.

In the short term I'm focused on 2.0.x and 1.3.x (see patch posted
previously), and not tracking the request phase but tracking the
actual module name. Both of these endeavors are irrespective of
whether or not any Apache httpd folks want the changes in Apache.

For now my 2.0.x patch for tracking the module name only affects a few
hooks which, in my experience, are most in need of displaying the
active module since they are most likely to stall or crash.  The
mechanism is easily extensible to other hooks, although I would need
to create abstractions for the different hook flavors to avoid lots of
the same code.  Also, as discussed previously the performance may be
an issue if everything is instrumented, so simply controlling it via
ExtendedStatus On would not be cool (need to measure).

The bulk of this 2.0.x change is attached.  There also is this hack to
scoreboard.h where I snarf an unmapped byte, which is the same thing I
did in the patch for 1.3 which I posted previously.

struct worker_score {
    int thread_num;
    apr_os_thread_t tid;
    unsigned char status;
    unsigned char short_module_index; /* does not change layout on XXX
platforms */
    unsigned long access_count;
    apr_off_t     bytes_served;

mod_status has the obvious stuff to format module name when "module"
query arg is added.  I'll be updating mod_whatkilledus-for-2.0.x to
identify the crashed module when the scoreboard indicates that one was

View raw message