On Tue, Dec 31, 2013 at 9:55 AM, Chad <innocentkil...@gmail.com> wrote:
> I'm starting a new RFC to discuss ways we can improve our PHP profiling. > > https://www.mediawiki.org/wiki/Requests_for_comment/Better_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) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
