You might like my Django SQL Inspector which aggregates many SQL queries across many requests.
Have you thought that instead of sending the results to elasticsearch? Instead of using something like newrelic this could take it's place..
What's nice about the current setup is that it takes very little effort to get up and running but I suppose could make that configurable...
I've put a lot of love into it and it can give you tons of information about your application.
Using celery or django-rq to delay the processing also seems reasonable.
I think the Elasticsearch/Celery option is a good shout if this were to ever be used in production. Celery would help with the issue of response time but it wouldn't solve the load impact on the database (although I guess could also configure a different SQL database in Django).
I will certainly do some investigation into this at some point :)
I'm a little confused by this page though: http://mtford.co.uk/silk/request/1907/profiling/. Why is wrapped_target listed so many times for a single blog post query? Is there a hierarchy to the profile calls that's not shown? Oh, does it go deepest level to highest level calls?
Any ideas if that's the case?
If, after installing Silk, I use admin to update a record, I get "You cannot access body after reading from request's data stream" - this applies across all admin models and pages. It's not really that big a deal, as I rarely use the admin pages now, but it might have knock-on effects that I haven't seen yet. (Commenting out Silk in the installed apps list clears the problem up straight away.)
I'll ping you an email with the stack trace.
@mtford great job!
