Chris Adams

The modern web browsers have increasingly good tools for monitoring client-side performance - perhaps the best being the WebKit Timeline but there's only so much you can improve when most of the processing happens on the server side.

For those of us writing Django apps, there are fairly good tools for monitoring database performance by tracking slow queries (e.g. django-debug-toolbar or django-devserver) but there's not much else out there for measuring any of the other sources of delay (filesystem or network I/O, inefficient Python code, etc.) except the lower-level profile module. Most of these tools have the problem that getting useful data out requires a bit of work manipulating data, filtering out noise and assigning blame to the correct place (e.g. it's more likely that your code is calling an API poorly rather than that underlying API's implementation) - simply sorting a two-dimensional list is not enough for a large application.

One of the challenges for building better tools is building an interface which can interact with potentially very large amounts of trace data. Fortunately, Google's Chrome team added server-side trace support to SpeedTracer, making it possible for us to focus entirely on the problem of getting that data and simply reuse the work which the Chrome team has already done building the SpeedTracer UI and making it fast. Best of all, it uses only HTTP headers so there's no way for it to interfere with your sites' generated HTML and it works for any type of resource as long as it's served by Django.

Getting Started

1. Download and install Speed Tracer
2. Download and install my django-sugar fork - e.g. pip install git://github.com/acdha/django-sugar.git
3. Add "sugar" to your INSTALLED_APPS
4. Add "sugar.middleware.speedtracer. SpeedTracerMiddleware" to your MIDDLEWARE_CLASSES
5. Load your page inside Chrome with SpeedTracer enabled
6. Open SpeedTracer and expand the "Server Trace" in the page's detailed report which should look something like the picture above

Next steps

This has already proven itself to be somewhat handy for me at work but there's obvious improvement which could be made: this really should be converted into WSGI middleware so any Python-based webapp could benefit.

Inspiration

Thanks to Ilya Grigorik for his blog post about his racks-speedtracer module which inspired a night of tinkering last month. No thanks to my memory for not hitting publish sooner…