What does it measure?
Real User Monitoring details how long pages take to load and where the time is spent – from the moment the user clicks until the page has completed loading. Typically, for each click, a request is sent over the network to a server where it sits in a queue waiting to be processed. Eventually it hits the front of the line and is processed by the app creating a response. The response sent back over the network and is then loaded and rendered in the browser.
Here’s how New Relic displays page load time for for an app. It’s very similar to the timeline shown above except that network time is combined into the total round trip over the internet.
￼Page load time is broken down into five components:
Request queuing: The wait time between the web server and the application code.
Web application: The time spent in the application code.
Network: The time it takes for a request to make a round-trip over the internet.
DOM Processing: Time spent in the browser parsing and interpreting the HTML.
The graph makes it easy to see how a spike in one component, like network time, can affect overall page load times.
Page load time is further broken down by geographical location. For example, you can see how page load times vary around the planet.
The data is displayed in tables as well as maps, and you can render the geographical data many ways – by page load time, network time, heaviest users, Apdex, throughput and sessions.
The data is also sliced and diced by the pages on your site. You can easily find the most heavily used pages on your site and drill into their performance. And of course, you can easily link from the end user tier to the app tier for a particular page.
All the gory detail of what happens in the application for a particular request is at your fingertips.
You can also see what browsers people are using to view your site and how their performance varies.
How does it work?
You can turn RUM on/off via your application settings in New Relic. As well, you can turn RUM on/off via the agent’s configuration file (newrelic.yml – a ‘browser_monitoring auto_instrument’ flag has been introduced).
How do we do it?
New Relic operates a set of highly efficient data collectors. The collectors preprocess and aggregate browser metrics before sending them along to our analytics system for presentation. We’ve chosen a hybrid cloud data model to allow us to scale with demand. Currently, the collectors are performing with a 0.16 millisecond response time (i.e. to process each ping back from an end user browser) and we’re only consuming 5% of our server’s capabilities. This model will allow us to scale as demand grows. Just think – each time one of our customers gets a hit – so does New Relic.
RUM is also integrated with New Relic’s Apdex score – you can define a page load target time for your app to get a better view into your customer’s satisfaction. End user details are included in all of New Relic’s standard reports and emails. RUM is also integrated with New Relic’s alerting system so you can be notified when end user performance degrades – even when application performance does not.
It’s included at all price levels. If you don’t already use New Relic, you can always try it out for free with our “two minutes to first light” install. You’ll get insight into how long users are waiting for page loads, where they’re coming from, and if they are having different experiences based on where they are or what they’re using.