Skylight, a Ruby profiler, free for open source applications(blog.skylight.io)
blog.skylight.io
Skylight, a Ruby profiler, free for open source applications
http://blog.skylight.io/announcing-the-skylight-for-open-source-program/
33 comments
If you're building a Rails app, you should be using Skylight. It gives you:
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.
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.
https://www.appsignal.com has a great product, and works for Elixir / Phoenix too.
It also supports, profiling background jobs.
It also supports, profiling background jobs.
I wish they added freebsd support :(
Edit: wow, looks like they added[0] a few months ago! Awesome
0 - https://docs.appsignal.com/support/operating-systems.html#fr...
Edit: wow, looks like they added[0] a few months ago! Awesome
0 - https://docs.appsignal.com/support/operating-systems.html#fr...
Yeah we're using AppSignal, I do kind of miss Skylight's "agony" metric though.
Funny enough: also Rust production users.
Indeed, rust is amazing. Much thx to the likes of you for putting in those hours.
Do you find it significantly better than NewRelic?
NewRelic is much more comprehensive (they also have a "profiling" feature), but you rarely, if ever, find yourself needing any of the additional features. For the price, it's hard to beat Skylight. Also, we've found pganalyze to be an amazing bang for the buck.
That is debatable, insight NewRelic offers is kind of complementary. However at the price that is way, way, more.
Absolutely better.
Has anyone used New Relic and switched to Skylight or vice versa? Been looking for some comparisons [1].
[1]: https://twitter.com/sunnyrjuneja/status/951973556170215424
[1]: https://twitter.com/sunnyrjuneja/status/951973556170215424
I could never find anything actionable in NewRelic. Seems like interesting data, but nothing I could optimize for. Skylight has identified slow performing areas where we've worked on and watched a downward trend.
Come on, I love Skylight, but really! Slowest queries, slowest requests, breakdown of every hit into details how much time everything took. It gives you too much actionable data if you ask me. You can constantly optimize some slow-pokes, I have to remind myself to not optimize pages that are not most used.
Note to the Skylight marketing team: I had never heard of your service in 10 years of using Rails, even if it was something that could very valuable to me. But if I open the homepage what I see is:
"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.
"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.
I see that the logs and analysis will be open to everyone. I guess that's equivalent to using Travis, CircleCI, etc. on their free/open tiers. But API logs and analysis like Skylight performs can have much more unpredictable and sensitive info in them than test/build logs.
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.
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.
The short answer is no.
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...
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...
Good to know. Thanks.
Been using this on production for ~1 year now, no complaints so far!
“Skylight is a smart profiler for Ruby on Rails applications.”
For clarity, we also support almost all Rack-based frameworks in Ruby (including Sinatra):
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.
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.
As a further historical note that may interest HN users specifically, Skylight was the world's first production user of Rust (the Ruby gem they ship is written in it), dating back to well before Rust was even stable.
Which is mainly because Yehuda Katz (Rust core member) works at Skylight.
To be clear about the chronology here, wycats made the decision to go with Rust, then did a lot of work in Rust, then became a core team member. He chose Rust because of his needs in Skylight, not because he was already invested in Rust.
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
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
For slightly more context, I wrote the first lines of Rust code for Skylight as a spike at the end of 2013, and joined the Rust core team more than a year later. :)
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...
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...
Do you code in Ruby any more or is it all Rust these days? If you had to build a web app what would you use?
I split my time between Ruby, JavaScript (mostly with TypeScript) and Rust, with occasional Java and devops work. Of those, JavaScript (with TypeScript) is my predominant language at the moment, but the mix changes pretty often.
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.
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.
Interesting. I see, thanks. From your list Ember stands out, was not expecting that. Rails and Ember integration looks painful? Maybe using Rails 5 and API mode is the way to go.
Darn, you beat me to it.
Product blog operators, please see: https://news.ycombinator.com/item?id=16278142
Product blog operators, please see: https://news.ycombinator.com/item?id=16278142
Ok we've attempted to integrate that into the title.
[0] https://www.rust-lang.org/pdfs/Rust-Tilde-Whitepaper.pdf