| django-speedbar - Page performance profiling for django |
|---|
|
| django-speedbar instruments key events in the page loading process (database |
| queries, template rendering, url resolution, etc) and provides summary |
| information for each page load, as well as integration with Google Chrome |
SpeedTracer to show a tree of the events taking place in a page load. |
| It is designed to be run on live sites, with minimal performance impact. |
| Although all requests are monitored, results are only visible for users |
with the staff flag. |
| Installation |
To install django-speedbar add it to your installed apps, urls, and add the speedbar middleware.
# settings.py
INSTALLED_APPS = [
# ...
'speedbar',
# ...
]
# For best results put speedbar as near to the top of your middleware
# list as possible. django-speedbar listens to the django request_finished
# signal so actions performed by middleware higher up the stack will still
# be recorded, but will not be included in summary data.
MIDDLEWARE_CLASSES = [
'speedbar.middleware.SpeedbarMiddleware',
# ...
]# urls.py
urlpatterns = patterns('',
# ...
(r'^speedbar/', include('speedbar.urls')),
# ...
)To view the results in SpeedTracer you will also need to install the SpeedTracer plugin.
To include summary information in the page you can use the metric template tag.
{% load speedbar %}
<div class="speedbar">
<span>Overall: {% metric "overall" "time" %} ms</span>
<span>SQL: {% metric "sql" "count" %} ({% metric "sql" "time" %} ms)</span>
<!-- ... -->
</div>Configuration =====
django-speedbar has a number of configuration settings.
# Enable instrumentation of page load process
SPEEDBAR_ENABLE = True
# Enable the summary data template tags
SPEEDBAR_PANEL = True
# Include headers needed to show page generation profile tree in the
# Google Chrome SpeedTracer plugin.
SPEEDBAR_TRACE = True
# Include response headers with summary data for each request. These are
# intended for logging and are included in all requests, not just staff
# requests. If you turn this on we recommend configuring your load
# balancer to strip them before sending the response to the client.
SPEEDBAR_RESPONSE_HEADERS = False
# Configure which instrumentation modules to load. This should not
# normally be necessary for built in modules as they will only load
# if the relevant clients are installed, but is useful for adding
# additional custom modules.
SPEEDBAR_MODULES = [
'speedbar.modules.stacktracer', # Most other modules depend on this one
'speedbar.modules.pagetimer',
'speedbar.modules.sql',
'myproject.modules.sprockets',
# ...
]Status =====
We run our production systems with django-speedbar installed. However, the API is not stable and is likely to change. It does not yet have any default templates to make it easier to use the on-page features.
Similar projects =====
There are a number of similar projects you may want to consider as well as or instead of django-speedbar.
django-debug-toolbar -----Website: https://github.com/django-debug-toolbar/django-debug-toolbar
The swiss army knife of django page inspection. Mature, widely used, and with lots of plugins available. It has more of a focus on debugging and information, and less focus on performance measurement. We found it too slow to run on our sites in production.
New Relic ----Website: http://newrelic.com/
An in depth application monitoring platform. Very useful for observing trends in application performance and page load times. Less useful for drilling deep into individual page loads, and has support for a smaller set of external services. Commercial product.
django-live-profiler -----Website: http://invitebox.github.io/django-live-profiler/
Site wide profiler for django applications. I haven't used this, so cannot comment on it.
Credits ===== django-speedbar was primarily written by Theo Spears whilst working at Mixcloud.