The Scout Java Application Monitoring Agent is under active development and we have a few spots open in our alpha program. Email firstname.lastname@example.org for access.
For many Rubyists, Ruby is the first language that they learn and perhaps the only programming language that they know. Ruby provides an excellent gateway into the world of programming by allowing the newcomer to pick up its syntax rather quickly and allowing them to produce a working application within hours or even minutes using frameworks such as Rails.
Regardless of how one came to learn Ruby, I believe that programmers can benefit from learning another language that is fundamentally different, such as Java.
I'll provide a brief introduction into the world of Java from the perspective of a Rubyist. For the sake of staying focused, I'm not going to cover the difference in syntax between the two languages as this is best picked up over time, nor am I going to get into the details of more advanced Java topics such as the Java memory model or concurrency. What I do want to do is give a brief overview of the language, and why I think learning Java can benefit a Ruby programmer. Finally, I plan to cover some popular Java tools and frameworks and how they correspond to those in the Ruby world.
Bella is my 10-year-old shepherd mix. I rescued her from a shelter in October 2005. Her favorite activity is diving and running into snow piles and catching snowballs - nothing else exists when there is snow flying around her! She never learned to fetch (or was never into it, anyway). Nowadays she keeps watch over our toddler and infant - especially around the dinner table or where there are kids snacks that leave crumbs.
Another fun tidbit: our 8-month-old is just learning to speak and her first word was "ella" - she can't pronounce the "b". She always looks for Bella in the room followed by "ella, ella".
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.