Skylight, a Ruby profiler, free for open source applications(blog.skylight.io) |
Skylight, a Ruby profiler, free for open source applications(blog.skylight.io) |
[0] https://www.rust-lang.org/pdfs/Rust-Tilde-Whitepaper.pdf
1. What's slow.
2. What's hit frequently.
This combined gives their "agony" ranking for you to fix problems that impact the most. In a very clean UI!
Terrific product. I wish I had Skylight for my Phoenix/Elixir stack.
It also supports, profiling background jobs.
Edit: wow, looks like they added[0] a few months ago! Awesome
0 - https://docs.appsignal.com/support/operating-systems.html#fr...
[1]: https://twitter.com/sunnyrjuneja/status/951973556170215424
"DO THE ANSWER DANCE". Cool looking weirdo characters dancing. Generic charts-filled dashboard screenshots. Comparatively very small text saying "learn why your app is slow".
If you hadn't been vouched by this HN thread, I would have never read below the fold to learn that you allow profiling Rails apps.
Does this mean that all private fields needs be scrubbed in-app, before Skylight? For example, a hosted OSS service that includes e-mail addresses or location data in API query strings.
We work differently than other similar products, in that we rely heavily on aggregation, both for presenting useful data in the UI and also to keep our backend scalable. We don't keep around particular aspects of individual requests. Individual requests are essentially only used as "data points" to build statistical models about your app/endpoints. For example, any SQL queries are parsed and sanitized on your server before they are sent to us[1].
That probably sounds more involved than it actually is in practice – you can see it for yourself on the dashboards for The Odin Project[2] and the Homebrew formula browser[3]. The bottom line is that there is no way to get from the aggregated data back to an individual request.
[1] https://www.skylight.io/support/faqs#security
[2] https://oss.skylight.io/app/applications/g0gJSNnzYAws/recent...
[3] https://oss.skylight.io/app/applications/jut3BrkJo722/recent...
https://www.skylight.io/support/advanced-setup
We should probably update our copy to clarify this point in the prominent places where it isn't already clear.
Product blog operators, please see: https://news.ycombinator.com/item?id=16278142
https://blog.rust-lang.org/2014/12/12/Core-Team.html
> Yehuda Katz will be known to many in the Rust community for his work on the initial design and implementation of the Cargo project. He is also a co-founder of Tilde, which has been using Rust commercially in their Skylight product for quite some time
I was largely inspired by a blog post in June 2013 by Patrick Walton: Removing Garbage Collection From the Rust Language[1]
[1]: http://pcwalton.github.io/blog/2013/06/02/removing-garbage-c...
Skylight's stack is Rust and Ruby for the agent, Rails for the backend, Java for our data processing pipeline (essentially a custom data store) and Ember for virtually the entire front end. The graphs in Skylight are Ember components written in d3.
I still think that Rails is a great choice for most web apps, since (to this day) it provides an extremely productive baseline for building account management and working with third-party integrations, which turn out to be a surprising percentage of the total code (and an even higher percentage of backend code changes) in even an ambitious project like Skylight.
I also think it's reasonable to use something like Java or Rust for any heavy data-crunching your app might do, but I think people over-estimate which aspects of their application are truly performance and efficiency critical.