Got RUM (Real User Monitoring)?

This year I attended the O'Reilly Velocity Conference and had a very good experience.  Before I continue let me give a little of my background.  Most of the conferences that I have attended have been for developers or for a specific language.  The developers conferences all degrade into one large and endless commercial.  The programming language conferences turn into juvenile language bashing or a religious revival.  It takes a lot of patience to glean valuable insights from these conferences much like getting water from a dry sponge.  Velocity on the other hand was like drinking from a fire hose.  It is going to take months to get through the valuable information that was available.  One topic stood out almost ominously, the topic of this blog entry real user monitoring or RUM as I'll refer to it throughout the rest of this entry.

What is RUM?

RUM is a passive technology used for performance metrics and monitoring.  A simple definition is that it records all of the user interactions with a website.  That user creating the interactions could be another website, robot or human.  RUM is passive in that the collecting device gathers web traffic without having any effect on the site.  This hasn't always been the case in the past but the technology has improved to a point where there is no excuse to have it.  Passive monitoring differs from other types such as synthetic and automated web browsers in that it relies on actual inbound and outbound web traffic to take measurements.

Why use RUM?

The performance community for years have been preaching that site owners need to use real end-user monitoring tools, like Webpagetest.org, to get a real-world picture of performance.  For example, just because a test was successful doesn't mean users aren't experiencing problems:

• The user could be on a different browser than the test system.
• The user may be accessing a portion of the site that is not being tested.
• The user may be following a navigation path that was not anticipated.
• An outage could have been so brief that it occurred between two tests.
• A user's input data could cause the site to behave erratically.
• In a load-balanced situation a user could hit a failed component while the synthetic tests hits a working one.

There are infinite ways a site can be broken but still be working or hobbling along.  As I have experienced in my career, all the monitors could be green while the user experience is horrible.  RUM is a collection of technologies that capture, analyze and report a site's performance and availability from an actual visitor's perspective.  RUM may involve sniffing a network connection, adding JavaScript to web-pages, installing agents on boxes or any combination thereof.

Simple RUM!


If you are already using Google Analytics you already are instrumented for RUM!  Take a look at the Real-Time pages for the RUM reports.  It will open up a whole new vista for you.  Another simple implementation is using boomerang.

boomerang always comes back, except when it hits something.

Boomerang.js website (https://github.com/lognormal/boomerang) is a piece of JavaScript code that you insert into your pages that captures measures for a whole range of performance characteristics from an actual user's interactions.  I found that using Google Analytics' RealTime to be the easiest way to get RUM up and running and boomerang.js second to that.


Note: Here is how I got my nickname/alias 'oldstinger'.  In high school I played the strong safety/outside linebacker position and was known for my hard hits.  So one day my coach accidentally slurred my last name to 'stingham' instead of 'stringham'.  My friend said that yeah the hits sting.  Thus 'stinger' came into being.  Now that I am getting grey hairs it has become 'oldstinger'. :)