If you've been around the Ruby/Rails ecosystem for a bit you've likely heard the term 'background job' or 'offline processing'. But what does that actually mean? How do you know which tasks are suitable to be processed 'in the background'? Once you define those tasks, how do pick the right background job framework for your application?
In this post I'll cover all of the above, as well as compare and contrast a few of the leading Ruby background job frameworks.
High monitoring overhead is a silent killer: your app's requests take longer, throughput capacity shrinks, end users requests start stacking up in a request queue, you react by provisioning more servers, and finally, more servers == more $$$.
So how does Scout's overhead compare with the competition? To find out, we set up a suite of benchmarks comparing Scout's overhead to New Relic.
To ensure fair results, every part of these tests is open-source - from the Rails app we're benchmarking to the Rails log files generated by the benchmarks. We encourage you to analyze the raw data, try these benchmarks on your own, and let us know if you come to a different conclusion.
App monitoring overhead varies based on (1) instruments used and (2) available resources on the application server.
That in mind, we benchmarked agent overhead in the following scenarios:
Representative endpoint - this test hits 100 endpoints in a Rails app, with each controller-action conducting 21 database queries and rendering 20 view partials.
Expensive Endpoints - we simulate an app that does a lot of work to deliver a request (1k database queries and 1k view partials).
Fast Endpoints - we simulate an API-like controller-action that does very little work.
In these benchmarking tests, our metric of comparison will be response time. We're benchmarking a Rails 4.2.5 application running Ruby 2.2.3.
I've put the results below. Beneath this summary, you'll find details and analysis on each benchmark. The percentages below represent the increase in response time when each agent is installed. Lower is better:
Response Time Overhead Benchmarks
21 database queries and 20 view partials per controller-action.
1k database queries and 1k view partials per controller-action.
1 database query and no view partials per controller-action.
What's a Rails stacks look like in the wild these days? Most popular Rails version? Most popular Ruby? Is Delayed Job still hanging on?
If you're curious about the above, you've come to the right place. We collect gems used on the apps we monitor at Scout to assist with debugging issues and to prioritize libraries we want to instrument. This data set is across many hundreds of apps - while a small chunk of the Rails ecosystem, it's enough to shed light on usage.
Metrics for Christmas everyone! Get your metrics! We've added more metrics to Scout App Monitoring. These metrics will give you even greater visibility into the full request cycle of your Rails app:
Request Queuing - judging if you have enough capacity to serve all your traffic is one of the more difficult (and important) things to track. Measuring the time spent from when a request first hits your load balancer till when your Rails app starts handling the request is a big help. Large request queuing times means traffic is piling up waiting to be served.
Middleware instrumentation - we now instrument the middleware used in your app as well.
Additionally, we addressed a couple of quirks:
Slow requests were timestamped with the time the request started. Now, they are timestamped with the time the request COMPLETES. This aligns with how other tools (like MySQL slow query logs) handle logging slow method calls.
Addresses some skewing issues where metrics may be associated with a time slot a minute-or-two off the actual time.
The old agent required a config/scout_apm.yml file even if environment variables were used. The file is no longer needed. Issues with this mostly sprang up in CI systems.
Solidifying support for threaded app servers (such as Puma or Thin).
The engineering team at AcademicWorks, the leading provider of scholarship management solutions for public and private educational institutions, was frustrated. With over two million users and a datastore-heavy Rails app with hundreds of database instances, their ten-person development was feeling bogged down with the bloat of their existing application monitoring tool, New Relic.