httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Trawick" <traw...@gmail.com>
Subject Re: debug apache
Date Mon, 19 Jun 2006 11:07:00 GMT
On 6/18/06, Ruediger Pluem <rpluem@apache.org> wrote:
>
>
> On 06/18/2006 04:03 PM, Jeff Trawick wrote:
> >> > On 06/17/2006 08:57 AM, Alexander Lazic wrote:
> >> > > On Sam 17.06.2006 00:54, Ruediger Pluem wrote:
> >> > >> From my current point of view the answer is: No, this is not
> >> possible
> >> > >> out of the box.
> >> > >> It may be possible if you modify the hook macros.
> >
> >
> > yep
> >
> > Getting inside these macros is what enables diagnostic features such as
> >
> > a) mod_status display of where a request is being held up
>
> But this feature is not in our codebase, right? Is it a patch to the macros
> + an additional module that hooks itself into the status_hook? Just curious.

not in our code base

what I do is replace stuff like

  ap_run_handler (a macro)

with

  foo_run_handler (a function)

which will check ap_extended_status; if off, it will just "return
ap_run_handler";
otherwise, it essentially has the macro expansion, but it has the
following logic around the module call:

  worker_score->module_index = handler_modindexes[n];
  rv = pHook[n].dummy(r);
  if (rv != DECLINED) {
    worker_score->module_index = 0;
    apr_table_set(r->subprocess_env,
                        REQUEST_ENVVAR,
                        apr_psprintf(r->pool,
                                "(%s/%d/handler)",
                                modnames[handler_modindexes[n]],
                                rv);
    return rv;
  }

If we reach the end without a module handling it:
  worker_score->module_index = 0;
  return DECLINED;

At initialization, the handler_modindexes function is built to
correspond to the hook_array.

Meanwhile, mod_status and a few other diagnostic modules know how to
turn a module index into a module name.

I put this problem determination aid in four hook calls which have
proven interesting w.r.t. third-party modules: handler, access
checker, check user id, log transaction.  I didn't care about any
performance difference between a hook macro in mainline vs. call to a
function which checks ap_extended_status and then invokes the macro.
I did check the CPU usage difference between ExtendedStatus on and
ExtendedStatus off after adding this logic.  It is still in the
neighborhood of a 1-2% increase, which is well worth it.

--/--

dev@httpd or dev@apr?

Implementation wise, what we are using is not a simple function call
or two which could be cleanly inserted into the apr-util hook macro
expansion.  The problem determination aid is dependent on

* the data structures behind the hook macros
* the Apache module index, which needs to be stored in those data
structures or in a parallel data structure so that it can be accessed
efficiently while walking through the hook array
* the worker_score

If httpd *developers* are interested, we should decide what type of
processing is acceptable/required first and worry about whether it can
be fitted into apr second.  As I recall from the last discussion of
this perhaps 15 months ago, most all of the interest was from web
admin lurkers, and there was insufficient developer interest anyway.

Mime
View raw message