[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] Tracing and profiling blog post

On Thu, Oct 30, 2014 at 5:36 AM, Thomas Leonard <talex5@xxxxxxxxx> wrote:
> Here's what I have so far:
> https://github.com/talex5/mirage-profile/blob/new-api/lib/trace_stubs.mli
> https://github.com/talex5/mirage-profile/blob/new-api/lib/counter.mli
> There's not much here, but it would be good to keep this API stable as
> pretty much all mirage libraries will be using it.
> The API for controlling the tracing, dumping out events, etc is much
> less critical and can be changed later, as it only matters to the
> developer profiling their unikernel.
> Comments welcome!

Nice blog post; it was interesting to see some of the earlier
performance puzzles re-examined with your new tools.

Recently I found the Google trace-viewer [1] tool; it was built to
analyze performance issues in Chrome [2], is now being used for
Android, and the Go language may adopt it as well [3].  I think it
would be worthwhile to a) review their event types and JSON format [4]
for inspiration, and b) consider trace-viewer as an alternative viewer
for some use cases.

As an experiment, I manually instrumented mirage-www with trace-viewer
JSON output, and the result is here [5].  Download that file, open
about://tracing in Chrome, then Load the .trace file.  (Failing that,
you can get the trace-viewer source [1] and run the dev_server, or
view the self-contained HTML/JS version [6]).  Press '?' for help.

The trace shows a browser loading the mirage-www home page, from the
server's point-of-view.  At the top are some GC counters, captured
once per second; the (hard-to-see) vertical green lines represent Gc
alarm callbacks.  Below that are all of the HTTP requests and related
FS calls, organized by HTTP connection -- in the Cohttp callback, I
store the conn_id in a thread-local, and use that as a "thread ID"
when recording events.

Overall you should see that the browser used 6 concurrent connections
to load all of the resources on the home page, and that generating
index.html requires reading a lot of files.  It would be nice if I
could look deeper into Cohttp and FS with mirage-profile, but use
trace-viewer as the presentation format.  (So far I am using just a
few features of the trace output, there are other examples in the
test_data folder of [1]).

To be clear, I don't think that trace-viewer could present low-level
Lwt scheduling as well as mirage-trace-viewer does.  However, it could
be useful for viewing a unikernel's behavior from other perspectives.

[1] https://github.com/google/trace-viewer
[2] http://dev.chromium.org/developers/how-tos/trace-event-profiling-tool
(see: GOTRACE)
[5] https://s3.amazonaws.com/lnmx-public/mirage-www.trace
[6] https://s3.amazonaws.com/lnmx-public/mirage-www.html


MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.