The transaction trace is application monitoring. If you can't track a performance problem to a line-of-code, you aren't app monitoring.
However, there's a gaping hole in the quality of transaction traces today.
We've been instrumenting the quality of our traces since our launch, and noticed that 46% of the time spent in an average Rails request is in custom application code. This falls outside the instrumentation that we, and every other app monitoring service, like New Relic, provides.
Let's fix that.
It started with Stackprof
The release of Ruby 2.1 introduced a C-api for fetching ruby backtraces. What's great about this API? Here's Aman Gupta of GitHub:
rb_profile_frames()) api performs no allocations and adds minimal cpu overhead making it ideal for profiling, even in production environments.
However, with all of that visibility comes a problem: Stackprof output is difficult to decipher.
ScoutProf builds on StackProf: we're aiming to make all of that data easily decipherable plus work in threaded environments (like Puma). The key part to making it decipherable and actionable? The aggregation. From our docs:
ScoutProf attempts to sample your application every millisecond, capturing a snapshot backtrace of what is running in each thread. For each successful backtrace captured, that is a sample. Later, when we process the raw backtraces, identical traces get combined and the sample count is how many of each unique backtrace were seen.
Let's take a look at a trace from New Relic. Notice 2/3rds of the time is spent in "Controller":
If you inspect the detailed trace, you'll see the following:
Sad face :). That's a big black box of time.
Now, here's a trace to that same controller-action with ScoutProf:
The mystery of "Controller" time revealed: we're seeing a breakdown of time spent in our custom code with zero configuration.
The big consumer above is
ChartPartData#descriptors. What's going on there?
We're seeing the overhead of
ActiveRecord: all that ORM doesn't come for free. Now, who knows about this code? Let's find out with Scout's GitHub integration:
Looks like I should talk to Andre :).
Improving the performance of complex Ruby code is time-consuming: it frequently involves the coordination of several people on your team. We're hoping to make it easier to identify these bottlenecks and the humans that can solve them.
Our instructions for enabling ScoutProf are on our help site. Note that ScoutProf is in BETA.