AppNeta Launches Real User Monitoring for TraceView
by October 24, 2012

Filed under: Performance Monitoring

AppNeta no longer blogs on DevOps topics like this one.

Feel free to enjoy it, and check out what we can do for monitoring end user experience of the apps you use to drive your business at

I wrote two weeks ago with a preview of our Real User Monitoring (RUM) features, and today I’m excited to announce that RUM has arrived – available to all customers at no additional cost!  If you’re a TraceView user already, just log in and follow the instructions to get started.  If you’re not a TraceView customer yet, read on to find out what we’re so excited about and how it can help you understand and optimize your application’s end-user performance.

End User Experience 1

Look Under Your Seats: Browser Performance for Everybody!

Until today, TraceView focused primarily on providing visibility into the full server-side application stack, helping dev and ops find problems in the application, webservers, databases, and caches.  However, more and more application work—and latency—occurs in users’ browsers.  That’s why we built RUM with web developers in mind, extending visibility across the internet and into your customers’ pageloads as experienced by the browser.  A safe and low-overhead JavaScript injection based technique means TraceView is gathering not only server performance data but also network, DOM processing, and page render time.

What Does RUM Give You?

 Full Stack 1

In addition to the awesome full-stack application visibility, TraceView customers now have integrated client-side performance data for pageloads served from your app including:

  • Network time – this is the time the client spent requesting the initial pageload from your app and then receiving the response over the wire
  • Server time – time spent waiting on the application backend to return results (and, of course, our detailed full-stack tracing to help you break it down)
  • DOM processing time – time the client browser spent assembling the DOM – this corresponds to the document.ready() callback in jQuery
  • Page render time – time between when the DOM was assembled and all of the resources in the page were fully loaded
  • Take that data and break it down by page, geography, browser, and more

Head to our documentation to read more about RUM.

What’s Next?

We’ll be rolling out some exciting enhancements to our end-user visibility in the coming weeks.  Spoilers: includes client-side errors (!!).  There’s also a few server-side visibility enhancements in the pipe.  Stay tuned!

Author: Dan Kuebrich