Live data from Hacker News

Show HN: Silk, a profiling tool for Django

mtford.co.uk

11–20 of 25 posts

Re: Show HN: Silk, a profiling tool for Django

#13
post #9

Looks really nice. Have you thought that instead of sending the results to elasticsearch? Instead of using something like newrelic this could take it's place..

That's not a bad idea, it would probably be more natural than the rigid filters that are currently in place for the requests and profiles. As far as having this running in prod I've only really thought of siphoning off the results to celery or something similar to avoid impacting response time, but a spray and pray at Elasticsearch would work just as well.

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

Re: Show HN: Silk, a profiling tool for Django

#15
post #14

What is the overhead (roughly) for this guy? I do absolutely love the idea of using elasticsearch for this instead of a traditional database. Using celery or django-rq to delay the processing also seems reasonable.

Tbh, probably fairly bad atm. I haven't done anything empirical but atm Silk will create a record for every SQL query executed during the request/response cycle effectively doubling the number of queries. Not only that but it also saves down any non-binary HTTP body to a TextField, and this isn't yet configurable.

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 :)

Re: Show HN: Silk, a profiling tool for Django

#16
post #15
post #14

What is the overhead (roughly) for this guy? I do absolutely love the idea of using elasticsearch for this instead of a traditional database. Using celery or django-rq to delay the processing also seems reasonable.

Tbh, probably fairly bad atm. I haven't done anything empirical but atm Silk will create a record for every SQL query executed during the request/response cycle effectively doubling the number of queries. Not only that but it also saves down any non-binary HTTP body to a TextField, and this isn't yet configurable. I think the Elasticsearch/Celery option is a good shout if this were to ever be used in production. Cele…

StatsD might be better since you are just recording datapoints + text field I'm assuming.

https://pypi.python.org/pypi/python-statsd

Re: Show HN: Silk, a profiling tool for Django

#17
post #15

Earlier quoted context omitted.

Tbh, probably fairly bad atm. I haven't done anything empirical but atm Silk will create a record for every SQL query executed during the request/response cycle effectively doubling the number of queries. Not only that but it also saves down any non-binary HTTP body to a TextField, and this isn't yet configurable. I think the Elasticsearch/Celery option is a good shout if this were to ever be used in production. Cele…

StatsD might be better since you are just recording datapoints + text field I'm assuming. https://pypi.python.org/pypi/python-statsd

Sounds interesting... i'll take a look. The fact that its UDP would be helpful in avoiding the need for a dependency on celery/message queues.

What's it like in terms of getting the data back out?

Re: Show HN: Silk, a profiling tool for Django

#19
post #9

Looks really nice. Have you thought that instead of sending the results to elasticsearch? Instead of using something like newrelic this could take it's place..

If you are looking for something like newrelic you might want to give https://appenlight.com a try.

I've put a lot of love into it and it can give you tons of information about your application.

Re: Show HN: Silk, a profiling tool for Django

#20
post #17

Earlier quoted context omitted.

StatsD might be better since you are just recording datapoints + text field I'm assuming. https://pypi.python.org/pypi/python-statsd

Sounds interesting... i'll take a look. The fact that its UDP would be helpful in avoiding the need for a dependency on celery/message queues. What's it like in terms of getting the data back out?

You can write your plugin for the back end to dump it. It defaults to graphite which would be familiar enough I think.
Post reply on HN