httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Theo Schlossnagle <je...@omniti.com>
Subject Re: dtrace in apache
Date Sun, 24 Aug 2008 18:28:30 GMT

> From: rahul <rahul@Sun.COM>
> Date: 23 August 2008 03:30:37 EDT
> To: dev@httpd.apache.org
> Subject: dtrace in apache
> Reply-To: dev@httpd.apache.org
>
> Hi,
> I was reviewing the omniti labs dtrace functions, at
> http://labs.omniti.com/trac/project-dtrace/browser/trunk/apache22/apr-util-hook-probes.patch
> This patch (util-hook) is committed into apache already.
>
> I was concerned that quite a few were just tracing function  
> boundaries,
> which the dtrace does already for us with out the necessity of USDT  
> probes
> baked into the code.
>
> For e.g in APR_IMPLEMENT_XXX macros, the below are inserted.
> but APR_IMPLEMENT_XXX macros already create function boundaries when
> they are called and these probes effectively duplicate the
> instrumentation available.

Are you talking about the pid provider?  If so, that leaves a lot to  
be desired.  Specifically when you have many processes (1024 Apache  
processs) or even rapid fork for new apache children which is  
sometimes case.  The pid provider is simply not designed for that as  
is evidenced by its poor usability under those circumstances.

This aren't tracing function boundaries, they are tracing "key"  
function boundaries.  And it allows access to the Apache request  
internals as they are passed as arguments.

We have used these probes in some key troubleshooting in production  
and pid probes would have not done the trick.

My two cents.

Please keep me on the cc.. I'm not on this list.

--
Theo Schlossnagle
Esoteric Curio -- http://lethargy.org/
OmniTI Computer Consulting, Inc. -- http://omniti.com/


Mime
View raw message