httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rahul <ra...@Sun.COM>
Subject Re: dtrace in apache
Date Mon, 25 Aug 2008 12:39:39 GMT
| >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.

You are correct, I was not thinking about a tracing a large number of
processes and pid provider falls quite short on that account.

thanks for pointing that out.


rahul.


Mime
View raw message