March 20 Derek

Updates to memcached, nginx monitoring

Comments

Colin Surprenant did some quality GitHub forking today, enhancing the monitoring for memcached and nginx.

• Current connections
• Current data MB
• Evictions
• Get count
• Get hits
• Get misses
• Max data MB
• Set count
• Total items

• Reading
• Requests
• Requests per/second
• Total
• Waiting
• Writing

Thanks to Mike Mangino and Luc Castera for their original work on the memcached and ngix plugins, respectively.

• memcached
• nginx

And just how did Colin, Mike, and Luc magically add this functionality to Scout? It’s easy – see our guide.

March 16 Derek

See Scout's big changes at Golden Gate Ruby Conference and RailsConf

2 comments

It’s been almost a year since we launched Scout, and over the past couple of months, we’ve been working on a big new release. We’ll be showing off Scout’s new features at the Golden Gate Ruby Conference on April 17th and 18th and at RailsConf on May 4th-7th.

Hope to see you in our booth!

February 12 Derek

Hardware Upgrade - Downtime 3pm-3:30pm

Comments

A quick note that we are continuing our hardware upgrades, and we’ll have downtime from 3pm-3:30pm PST today, February 12.

January 27 Derek

Scout reviewed in French

Posted in Updates |  Comments

If French suites you better than English (or you just like imagining yourself coding in a Paris coffee shop), Raphaël Emourgeon has penned a review of Scout in French.

Raphaël sums up Scout nicely:

Après avoir installé un gem et ajouté une tâche cron sur le serveur à surveiller, tout se fait à distance via le site Internet de Scoutapp. Il suffit de quelques clics pour installer un plugin sur une machine et commencer la surveillance. Les plugins font toute l’originalité du système puisqu’un plugin est un script Ruby qui peut faire tous les traitements imaginables et qui utilise ensuite l’API (très simple) de Scoutapp pour renvoyer des résultats.

P.S. If you’re like me and struggle with French, here’s Google’s attempt at the translation

January 19 Derek

Bigger Hardware = Downtime today, 1PM PST

Comments

We’re upgrading our infrastructure and Scout will be down from approximately 1PM – 1:30 PM PST.

Sorry for any inconvenience this may cause.

January 15 Derek

Solving the random Rails performance problem

Comments

Last week I uncovered a tricky performance problem on Scout I wanted to share.

In seemingly random fashion, when accessing my account home page, the render time was 5-6 seconds – way too slow. Other times, the render time would be far less than a second.

Here’s what I did to debug:

1. Tailed my production log
2. Opened up the mysql console
3. Generated a slow request
4. Ran the mysql SHOW PROCESSLIST command

Viola!

Plain as day, I saw a query taking 30+ seconds. A simple mysql EXPLAIN on the query revealed a missing index. A new index fixed the issue. This query was outside the Rails application – a background job – so I never saw the query when optimizing the application.

Checkout the impact on the DB server load:

It’s a great lesson that you really need the complete picture of your infrastructure when something goes wrong – just looking at the Rails application often doesn’t cut it.

P.S. You’ll love what’s coming up with Scout – finding these problems gets a lot easier.

Related:

• MySQL EXPLAIN
• MySQL SHOW PROCESSLIST
• What’s in store for Scout in 2009
• 4 Simple Steps to Detect & Fix Slow Rails Requests

January 06 Andre

What's in store for 2009 - beyond the numbers

Comments

2008 was a year full of numbers – 34% (fall of the the Dow Jones Industrial Average), $1.84B (Apple iPhone revenue), and $100M (cost of the Beijing Olympics Opening Ceremony).

But raw numbers are just the start – in 2009, our goal is to tell you what they mean:

• Your Rails application is slow. Now what? We’re bringing deeper, more actionable Rails instrumentation .
• You’ve got one hell of a memory leak. What’s going on? We’ll help you get a complete picture of your system right when the leak happens.
• You’re on the ski slopes but want to stay abreast of trends. We’ll help you get beyond raw numbers and alert you on trends.

And besides the functionality, there’ll be a new name for Scout in Q1!

Stay tuned for details in the coming weeks (or just subscribe to our RSS feed).

December 05 kevin

Say hey at Merb Day

Comments

Merb Day Atlanta – a “one-day, one-track conference for Ruby and Rails developers looking to learn Merb” – is this Saturday and Scout’s extremely proud to be one of its sponsors.

Our own Charles Brian Quinn and Matt Todd will be there, taking in the sights, and Matt will also be talking some code – he’s teaching a three-part tutorial with Michael Ivey on learning, using, and hacking Merb.

Be sure to say hey if you get the chance!

November 25 Derek

HopToAdd, Lighthouse Plugins Added

Comments

David Grandinetti of WeGoTo12 has added a pair of Scout plugins for 2 web services many Ruby on Rails developers are familiar with:

Lighthouse Open Tickets

This plugin tracks the total number of open tickets for a specific Lighthouse project. Lighthouse is a issue tracking, bug tracking, and project management hosted application.

HopToAd Unresolved Errors

This plugin tracks the number of unresolved errors in a HopToAdd project. HopToAdd is a hosted service for tracking and managing exceptions generated by a Rails application.

You can view a full list of available plugins in our plugin directory. The source of these plugins is available on Github.

September 23 Derek

A simple Rails performance tuning workflow

Comments

I really like Dan Mange’s workflow for Rails performance tuning:

1. Use curl for benchmarking. It’s good enough (and damn simple).
2. 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%.