| >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.
