Where RUM Fits In


There is a common misconception amongst those making their first foray into the world of Web performance monitoring that Real User Monitoring (RUM) is an advanced technique — not for the uninitiated, so to speak. The fact is that nothing could be further from the truth.

While it’s true that most entry-level Web monitoring services provide only basic up/down monitoring, the fact that RUM isn’t included in these offerings should by no means dissuade you from including it in your overall performance strategy.

However, most people new to the discipline of Web monitoring don’t start to part with the idea that RUM is either too trivial or too complicated until they have a better understanding of what it is and the value it provides.

RUM works just like it sounds — it essentially monitors, analyzes and reports on a website’s performance from the perspective of the user — which can be incredibly useful across a wide range of performance related issues — user experience being at the top of the list.

Rum technologies enable you to quickly discover whether your actual visitors are able to use your website and what their experience was like in a way that synthetic monitoring simply can’t. This is because synthetic monitoring revolves around designating and pre-scripting an action you believe represents a typical user behavior and monitoring that particular user path every X amount of minutes to ensure it’s available for you visitors.

RUM, on the other hand, captures exactly what each of your users is doing so that you can measure how your site is handling actual traffic, offering a real-world view of the visitor experience.

Let’s compare the two using the simple example of a shopping cart checkout.

In synthetic monitoring a script is created, that mimics the click stream a user would execute in order to complete his or her checkout. This synthetic script is run from a set client or browser, at set intervals from one or a revolving number of server locations. While this may provide you with a baseline for performance, offering you the ability to make sure you site is available and working, it’s only true for the click stream you created, in the client you chose, from the locations you designated, with the monitoring only occuring at the intervals you have set. The problem, which you can probably already see, is that human behavior is never quite that predictable — and this is where RUM thrives.

How often have hit the “back” button before checking out to confirm some details about an item? Have you ever closed a check out page only to return to it later in the day — and have you ever returned directly to the page by highlighting its cached URL in the address bar as you type in the website?

These are just a few examples of common variables that interrupt a user’s intended click path — each deviation representing a possible performance issue, none of which you would be aware of (unless you’re waiting to hear about it on Twitter) without RUM.

By capturing every interaction of every visit with RUM you can confidently determine if your site is working for everyone, everywhere — and if it isn’t, quickly identify where the problem is, what is causing it and (hopefully) address it quickly. This way you can see what performance looks like for users coming to your site via locations, click-paths and browsers different from those designated in your synthetic tests.

So the reality is that RUM is neither an excessive “add-on” nor a trivial non-essential with regards to performance monitoring. But by now you’re probably asking why you need synthetic monitoring at all — check back soon for my next post on how synthetic and RUM together provide a more holistic view of your website performance.

See also:


  1. wilsonmar says:

    Good article, Scott. There’s one use for RUM that should be mentioned because of its production usage — that of keeping instances of modules in memory rather than being swapped out due to inactivity. This is for those early risers who hit a site before others in their timezone. Without RUM, the early birds would have to wait for the module to load.

    • David Clark says:

      The RUM tools I have used, HP Rum and CA/Wily CEM, wouldn’t affect modules in memory. They are passive in that they look at packets usually through a mirror port on a switch or a device like annue. Their limitation is also that if there is no user traffic then there is no rum data so the complimentary tool is what we called synthetic transactions. Basically just web requests from tools to mimic users requesting pages. This tool would keep modules in memory and it would also account for the ‘midnight crash’ problem for Ops. That is a service goes down off hours – assuming no other system/process monitoring – and no one is accessing it. Running transactions every so many minutes would account for this scenario.

Speak Your Mind