Measure avg time per HTTP request for SQL queries

[atereshkin]

[gourneau]

You can close this one 👍

[atereshkin]

@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]

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.

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]

@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.