Probably not a good idea to keep your profiler open to the world as long as you allow reading from arbitrary files. After a bit of fiddling around I was able to read your secret key from the settings file. It starts with 'es!b3'. And your soundcloud password. Sorry.
Very cool, this seems much nicer than using hotshot to profile Django.<p>I'm a little confused by this page though: <a href="http://mtford.co.uk/silk/request/1907/profiling/" rel="nofollow">http://mtford.co.uk/silk/request/1907/profiling/</a>. 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?
Looks very interesting! We currently use django debug toolbar for profiling, which seems to have a lot of overlap. I like how Silk stores the profiles of multiple requests - that seems to be a nice differentiator. What else? Thanks for the awesome contribution to the Django community!
This is a really great tool, massive fan, made some good use of it in the ~15 hours since I installed it yesterday evening. Are you aware it seems to bork the admin interface?<p>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.)<p>I'll ping you an email with the stack trace.
Looks really nice.<p>Have you thought that instead of sending the results to elasticsearch? Instead of using something like newrelic this could take it's place..
I wrote <a href="https://github.com/rory/django-sql-inspector" rel="nofollow">https://github.com/rory/django-sql-inspector</a> a django app to profile SQL queries done in multiple pages, including showing stack trace of where it's being called. You can find out which function(s) are responsible for long SQL requests.
What is the overhead (roughly) for this guy? I do absolutely <i>love</i> the idea of using elasticsearch for this instead of a traditional database.<p>Using celery or django-rq to delay the processing also seems reasonable.
After reading through this intro, it isn't clear to me if I can use the decorator or context manager to profile code outside the request/response cycle.<p>Any ideas if that's the case?
For people interested in production monitoring I've created <a href="https://appenlight.com" rel="nofollow">https://appenlight.com</a> - and our python middleware will integrate and start timing django applications without any code changes required (except 3 lines to load middleware itself).<p>@mtford great job!