search

InviteBox / django-live-profiler

A database access profiler for Django-based applications that can be ran in production
194 stars 44 forks source link

Measure avg time per HTTP request for SQL queries #5

Open atereshkin opened 11 years ago

gourneau commented 11 years ago

You can close this one :+1:

atereshkin commented 11 years ago

@gourneau not yet, I think. The average time it displays right now is per SQL query while what I meant with this issue is average time per HTTP request. Now that I think about it, it might be not particularly useful considering it's strictly proportional to total time. I am editing title for clarity, but need to think if it's really worth doing.

gourneau commented 11 years ago

Ah gotcha.

I wrote a simple little Flask server that is an endpoint for boomerang data. It is a nice JavaScript tool that will phone home lots of metrics about the end users load times. The most interested one to me is 't_done' which is the total load time. I am using morris.js to make a nice little graph.

anode

Right now my little server is in written with Flask, so that it can collect metrics from a number of sites.

I think this would nice a nice addition to django-live-profiler, and I can help write it is you agree. Check out the mega alpha version I just threw up at https://github.com/gourneau/anode

atereshkin commented 11 years ago

@gourneau that would would be a welcome addition. However it's not a small undertaking. Here's why:

Despite "django" in the name, I'd really like to keep django-live-profiler as portable as possible. Right now there's actually very little django-specific in it. It consists of 3 "components" that talk to each other via 0mq:

  1. Aggregation daemon. This is the backend that collects and stores the stats. It's completely agnostic to the framework (or for that matter, language) of the application being profiled.
  2. Instrumentation. The hooks that measure execution time. This is the Django-specific part.
  3. Visualization. Based on Django for simplicity but really it's mostly js and server side can be trivially ported to any other framework.

It's also my goal to keep the visualization component universal so that custom instrumentation / metrics collection mechanism can be added without having to implement respective custom visualization.

So the way forward with incorporating your code would be:

  1. Implement a gateway server that would receive data from JS and send it to aggregation daemon. In theory that could be done with Flask, but it would be much more logical to make it Django-based so that the profiler remains as plug and play as possible.
  2. Implement instrumentation for Django - I'd do it by injecting the JS using middleware, but it could also be a template tag.
  3. Port visualization to the existing framework.

As you can see it's quite a bit of work. I will participate but for the next couple of weeks I'm over capacity :( Let me know if you are up to the task and I'll add you as a contributor.