Normally, processing of a request proceeds quite normally towards
completion.  Dependencies on external input however can impact normal
processing enough that requests can be hung.  (connections to LDAP
server timing out?  somebody decided to play with the database in the
middle of the day and remote application requests are stalled?)  Add
to that a loop here and there and it gets more exciting.  Having a
clue about the phase where a request is stalled (looping) can
drastically speed up resolution of the problem.  Stalling in access
checking vs. stalling while waiting for a remote application to
generate the response have quite different causes and often have to be
diagnosed by two different support teams/vendors (which themselves may
be different from the web server support team/vendor).

By tracking the active request phase, it can be displayed by
mod_status and can provide a quick guide to where work is piling up,
since 'W' doesn't help much when some of the phases covered by 'W' are
much more fragile than anything Apache does.

Here's a sample mod_status view:
http://httpd.apache.org/~trawick/active_phase.jpg

Knowing in which phase a web server thread crashed is also very
helpful.  With this patch and a few tweaks of its own,
mod_whatkilledus can display which request phase (if any) crashed, as
shown below:

[Sat Feb 26 14:46:30 2005] pid 8898 mod_whatkilledus sig 11 crash
[Sat Feb 26 14:46:30 2005] pid 8898 mod_whatkilledus active request
phase: translate
[Sat Feb 26 14:46:30 2005] pid 8898 mod_whatkilledus active
connection: 127.0.0.1:33047->127.0.0.1:8080 (conn_rec 81ebe70)
[Sat Feb 26 14:46:30 2005] pid 8898 mod_whatkilledus active request
(request_rec 81fbd00):
GET /silly?fn=translate_crash
[Sat Feb 26 14:46:30 2005] pid 8898 mod_whatkilledus end of report

An initial patch is at
http://httpd.apache.org/~trawick/active_phase.patch.  mod_status may
need to require a query option in order to spit out the new
information.

Any ideas for saving the information in a less intrusive way?

I have a patch in the works for 1.3 which implements the same basic
idea but via the module name instead of the active phase.  I don't
know how to do that for 2.x.  Either the module name or the phase can
be a big help, though I prefer knowing the module.

Reply via email to