On Tue, Dec 31, 2013 at 9:55 AM, Chad <innocentkiller(a)gmail.com> wrote:
I'm starting a new RFC to discuss ways we can
improve our PHP profiling.
Please feel free to help expand and/or comment on the talk page if you've
got ideas :)
Apropos of wfProfileIn/Out:
"A tracing infrastructure that relies on active collaboration from
application-level developers in order to function becomes extremely
fragile, and is often broken due to instrumentation bugs or omissions,
therefore violating the ubiquity requirement. This is especially important
in a fast-paced development environment such as ours."
From "Dapper, a Large-Scale Distributed Systems
Tracing Infrastructure" http://research.google.com/pubs/pub36356.html
It's a really cool paper. Here's how Dapper makes it possible to instrument
Google's distributed infrastructure:
* When a thread handles a traced control path, Dapper attaches a trace
context to thread-local storage. A trace context is a small and easily
copyable container of span attributes such as trace and span ids.
* When computation is deferred or made asynchronous, most Google developers
use a common control flow library to construct callbacks and schedule them
in a thread pool or other executor. Dapper ensures that all such callbacks
store the trace context of their creator, and this trace context is
associated with the appropriate thread when the callback is invoked. In
this way, the Dapper ids used for trace reconstruction are able to follow
asynchronous control paths transparently.
* Nearly all of Google’s inter-process communication is built around a
single RPC framework with bindings in both C++ and Java. We have
instrumented that framework to define spans around all RPCs. The span and
trace ids are transmitted from client to server for traced RPCs.
(cf pg 4)