September 23, 2008 by Derek
no comments 
I really like Dan Mange’s workflow for Rails performance tuning:
- Use
curl for benchmarking. It’s good enough (and damn simple).
- Use the ruby-prof gem along with an optional request parameter so you can profile any action, any time.
Dan also does a solid job explaining CPU time and what if means for your Rails app. A snippet:
At CarePages we have an Apache log that logs the controller, action, and Rails runtime. We run a script that groups the runtimes by controller and action, and then calculates the total runtime for a controller/action divided by the total runtime for all requests. What we found the first time we did this was that one of our pages was taking nearly 40% of the overall CPU time. It wasn’t the slowest page, but it was the most frequently hit page. We had two other pages that were taking about 19% and 13% of the overall CPU time. This gave us a good place to start – if we could make the 40% page twice as fast, we would lower our overall CPU usage by 20%.
September 09, 2008 by Derek
Posted in HowTo | no comments
Life as a cross-dresser must be unnerving. I could buy a wig, put some makeup on my adam’s apple. Buy a skirt. Does a sock-filled bra work for my bosom?
With a bit of mood lighting, I might actually look like a woman, but it would be difficult to relax. Knowing my manhood could be exposed in a multitude of ways – some stubble on my chin, hair on my legs, forgetting to make my voice less deep, etc. would leave me on-edge.
In some ways, I feel like I identified with cross-dressers before we solidified our Rails monitoring stack over the past year. I just felt vulnerable – that one wrong move could send our Rails stack tumbling.
We’ve standardized our setup, and I thought I’d share the 3 tools we’re using that make me feel much less like a cross-dresser these days.
The 3 pillars of our Rails monitoring stack
We break Rails monitoring into the 3 parts below (along with the tools we use):
Process Monitoring
|
System Performance
|
Exception Notifications
|
“The Diaper”
A safeguard for emergencies
|
“The Nerves”
Preventing future problems
|
“The Megaphone”
A loud voice when your app is breaking
|
|
Monit
|
Scout
|
Exception Notification plugin
|
|
Ensure Mongrels are running & restart leaking processes
|
Catch disturbing trends before they become problems – disk space usage,
server load, slow requests, etc.
|
Organizing and collecting application exceptions
|
So, to be clear, even though we built Scout, we use a combination of tools to make sure our Rails apps are running.
Read more... 
August 29, 2008 by Derek
no comments
Plot a week of data. A month. A year. We’re not picky – choose any time range and Scout plots the data in real-time.
You’ve always been able to graph as much data as your plan allows on Scout, but now it’s a whole lot faster. It takes a lot of horsepower for graphing – in fact, some monitoring products limit you to 24 hours of data. Some give you access to more, but you’re in for long wait. When you’re making serious decisions about Rails performance, we think you need to see as much as data as quickly as possible.
Watch a 1 min. 34 sec. Quicktime clip that shows our new graphing engine in action:
If you are an existing Scout user, note that you can now edit your default plugin graphs in-place – there’s no need to create a separate graph. You have the option to save your changes to the graph so it loads with the new settings next time you view the plugin.
August 22, 2008 by James
Posted in Plugins, Updates | no comments
The number one requested plugin for Scout has been a Phusion Passenger monitor. I’m happy to report that is now available.
Using the new Passenger Monitor plugin, Scout can keep track of Passenger’s VM size, process count, and the amount of private memory it has squirreled away. Aside from just tracking these numbers for graphs, you can also elect to be emailed if any of these statistics crosses a line you indicate. As an added bonus, this plugin also tracks the same statistics for the Apache instance managing Passenger.
Passenger has quickly become a great new way to deploy Rails applications and we want to make sure Scout is keeping up with the curve.
August 11, 2008 by Derek
no comments
Ensuring 15 Rails apps are running smoothly can be a real chore, especially when they have core pieces that fall outside the typical monitoring stack. Mike Mangino of Chicago-based Elevated Rails recently wrote about consolidating his Rails monitoring efforts using Scout:
This simple interface to reporting and alerting is incredibly powerful. What makes it even more powerful is the ease with which you can install plugins.
...
So far, using Scout has been a real joy. That’s something I never thought I would say about a monitoring tool.
Mike has open-sourced much of his work, publishing his plugins for Scout in our directory:
You can fork and/or follow Mike’s Scout plugins at GitHub.
August 05, 2008 by Charles
Posted in Updates | no comments
You can now follow our commits to Scout plugins at our GitHub Repository.
GitHub makes it easy to find out when new plugins are created. Feel free to fork us (as long as forking is legal in your part of the world).
Quick note – remember to use the raw format when using your own plugins from GitHub by appending ?raw=true to the plugin script URL.
Also see:
July 29, 2008 by Derek
Posted in HowTo | 11 comments
In Blink, Malcom Gladwell’s book on split-second decisions, Gladwell tells the story of how the Emergency Department at Chicago’s Cook County Hospital changed their process for diagnosing chest pain.
Dr. Brendan Reilly instituted a simple test to determine whether a patient was suffering from a heart attack. It combined just 4 questions with the results of an ECG. This simple test was 70% better than the barrage of questions previously asked by hospital staff to identify patients that weren’t having a heart attack and was nearly 20% better at identifying patients that were having heart attacks.
More information on the patient’s symptoms often led to an incorrect diagnosis. It distracted doctors from the real issues.
I’ve seen this many times with developers trying to debug performance issues in Rails applications. They look at outliers instead of the obvious culprits. It’s part of the reason I’ve never felt a need for a deep, detailed Rails monitoring application (i.e. – benchmarks from the controller to the database level on every request).
The majority of the time, our performance problems have nothing to do with the Rails framework (and we’ve worked through a lot of issues since we started building Rails apps in 2005). Why benchmark the entire request cycle when the vast majority of issues are isolated at the database layer? After I’ve ruled out the database, I can see benchmarking a single request (there’s a great free tool below), but I simply don’t want the other, often irrelevant information clouding my mind.
The root symptom we want to avoid in our apps is slow requests. Our Scout plugin for analyzing slow Rails requests has been installed nearly 250 times, so we’re not alone there.
Read more...
July 03, 2008 by Charles
Posted in HowTo, Examples | no comments
Amazon’s Elastic Compute Cloud (Amazon EC2) Service is changing how we approach computing infrastructure. Scout is an ideal monitoring solution for Ruby on Rails application servers on EC2 instances.
Why use Scout for monitoring your EC2 instances?
- Just a single line of code to add the client
- No complicated scripts to configure – choose what you want to monitor through the Scout web interface
- Easy to re-use or view statistical data once an instance has terminated
Overview
The basic process for EC2 monitoring works like this: You create a new client that you want to use as a template . You can then clone this client (and all of its plugins) using the scout clone command, which can be added to the boot/startup script on your AMI.
Read on for the Step-by-Step.
Read more...
June 09, 2008 by Derek
Posted in Updates | no comments
We’ve released the 2nd version of our Scout client. What I love about this release is that it doesn’t make anything more complex or break compatibility with our first release. It just makes writing plugins easier.
For example – lets say you want to generate an alert. How’s this for simplicity?
class INeedASandwich < Scout::Plugin
def build_report
alert(:subject => "Get me a sandwich")
end
end
We’ve also made the process for managing memory (data stored on the client between runs of the plugin) easier to work with. Memory is a great tool for storing state.
For example:
class INeedASandwich < Scout::Plugin
def build_report
if memory(:am_i_hungry)
alert(:subject => "Get me a sandwich")
remember(:am_i_hungry => false)
else
remember(:am_i_hungry => true)
end
end
end
As always, updating to the latest release is as simple as:
gem install scout [1]
gem install scout --source http://gems.scoutapp.com/
[1] Rubyforge is slow to update, in the meantime, use our gem server mirror
June 06, 2008 by Derek
no comments
Robin Ward of Forumwarz has released a MySQL slow queries plugin for Scout that does exactly what you’d expect: sends an alert when a slow query is run.
The alert contains the full query along with the query time:
Note that you’ll need to enable slow query logging in your MySQL config file, but that’s just a 2 line change. See the MySQL Slow Queries directory entry for more information.
