Magicians never share their secrets. But we do. Sign up for our Ruby Magic email series and receive deep insights about garbage collection, memory allocation, concurrency and much more.
With our new event type graphs it will be a lot easier to quickly pin-point the cause of a major slowdown of your application.
Before event type graphs, whenever your had a major increase in response times, you had to navigate to individual samples and check the event tree to determine what part of you app caused it.
With the new event type graphs this becomes a lot easier.
In AppSignal itself we use a ton of instrumentation to get detailed information about each step our background workers perform.
Here’s an example of our worker code:
1 2 3
data = ActiveSupport::Notifications.instrument('decode.protobuf') do PushProtocol::CollectorPayload.decode(protobuf) end
We use the ActiveSupport Notifications (Rails) standard of separating the action from the event group with a dot. In the example above the action is
decode in the group
protobuf. It’s the groups of all these instrumentations that end up in our Event graphs.
Lets take a real-life example of a major slowdown in our app we experienced a few days ago. Suddenly the duration of our background jobs increased from a few hundred miliseconds to an average of 4 seconds per job.
Without the event type graphs, we’d have to go to individual performance incidents and check the slowest event for each incident to figure out what part of our application is causing the slowdown.
With the graphs we can see in once instance that
moped is causing the slowdown, taking up an average of 3.2 seconds per job.
we immediately know that we should check what’s happening to our MongoDB cluster.
Event graphs are shown in a relative form and an absolute form.
The absolute form, showing actual durations is useful in case of a major slowdown as you can easily spot what event group is causing issues.
We use the relative graph to spot trends over long timeframes. We can see that our database or our view rendering is taking up more and more time of each individual request, pointing us to possible performance gains we can make.
By default, Rails will instrument a number of actions, such as:
AppSignal will create instrumentation for a number of 3rd party libraries such as:
Together these instrumentations cover the bases of any app: view rendering, database queries and application code (controllers/background jobs).
We recommend to instrument anything that might be a performance issue, such as making external requests and running complex operations.
For the best results you should not make too many groups, as graphs become harder to read.
These event type graphs are available for anyone using AppSignal gem
1.0 or above.