Giving your web host access to your Scout account

By Derek Bullet_white Posted in HowTo Bullet_white Comments Comments

A couple of times already, we’ve seen users give their web host access to their Scout account.

It’s a big help when debugging problems – especially things that a basic monitoring tool might not pick up (like slow web requests).

Read More →

 

How we handle background jobs

By Derek Bullet_white Posted in HowTo Bullet_white Comments Comments

We run background jobs on our Scout servers. Lots of them.

As we’ve grown, they’ve used dramatically more resources. We needed a way to simmer them down. Most of these jobs load the entire Rails environment – that’s a hefty overhead.

We’ve modified how we run background jobs and we’re seeing great results. If you’re interested in what we did, checkout Charles’ post on our Highgroove blog.

And finally, here’s the obligatory semi-promotional graph, generated by Scout, of how the load dramatically decreased after implementation:

Scout ~ Edit Graph

 

Recording Historical Data in Scout

By Derek Bullet_white Posted in HowTo Bullet_white Comments Comments

By default, when you create a report in Scout, we assume that the data corresponds to the time the report was submitted.

Sometimes this isn’t the case – for example, you can retrieve the number of subscribers to your RSS feeds in Feedburner, but not from the current day.

You can override the time Scout records the data in a Plugin with the special :scout_time report key.

Here’s an example:


# typical report data 
{:circulation => 1000}

# correspond the data w/ February 24, 2008
{:circulation => 1000, :scout_time => Time.parse("2/24/08")}

When displaying the data on a graph, the data will be shown on 2/24 and not the current date:

Scout ~ Derek Laptop

Learn more about creating Scout Plugins

 

Taking the guesswork out of scaling

By Derek Bullet_white Posted in Examples Bullet_white Comments Comments

Determining a web application’s hardware resources isn’t easy (or cheap). Frankly, it’s often just guesswork. Even when you build benchmarking scripts, they can miss key behaviors and ignore important metrics.

Scaling becomes a lot less stressful when you can quickly compare a history of your application data with server performance.

For example, we did this to get a better understanding of how our Scout server performed during our invitation process. The graph below was generated through Scout and shows the relationship between user accounts and the server load. As we expected, the overall load on the server increased as the number of accounts increased. Scout shows us how this data is correlated – it gives us an idea of how many accounts our current hardware can support.

Scout Accounts vs. Server Load
accounts vs load

It’s trivial process to regularly feed Scout your application data (user signups, orders, revenue, etc):

  1. Start with this Rails App Plugin Sample (this assumes a Ruby on Rails application, but you can do this with any framework/language)
  2. Grab your application data – just use ActiveRecord!
  3. Put the plugin on your server (can protect behind basic auth)
  4. Add the plugin
 

Track Active Logins & more

By Derek Bullet_white Posted in Plugins Bullet_white Comments Comments

Ever wanted to track how many people are logged into your server? Mark Hasse built an Active Logins plugin that does just that, returning the total number of people logged in via console, ssh, telnet, etc.

Mark has built several other plugins as well:

It’s easy to create a Scout a plugin and we’re here to help. Some useful plugin resources:
 

Monitoring Your Rails Sessions With Scout

By Derek Bullet_white Posted in Plugins Bullet_white Comments Comments

An oft-forgotten maintenance issue on Ruby on Rails applications is forgetting to expire old sessions. Lots of sessions in your database can dramatically slow performance.

You can use a cron job to expire old sessions, but it’s not always foolproof. We’ve seen timeouts when attempting to delete lots of session records and it’s not out of the range of possibilities to mistakenly disable multiple cron jobs.

Tim Morgan provided the inspiration for our latest plugin, Rails Session Monitoring. The plugin is dirt simple, reporting back the total number of sessions and the number of old sessions (you can define what constitutes old – the default is 14 days).

Here’s what I saw when I ran it on of our apps:

sessions

This is also the type of plugin that you don’t really need to run frequently – once-per-day is probably fine.

 

Older posts: 1 ... 47 48 49 50 51 ... 68