Saving Customers 75 Hours per Month With Real User Monitoring

Today, I’d like to share how we use Real User Monitoring to improve Raygun for our customers. This is an ongoing series about how we leverage our monitoring tools to make our product better. I hope it inspires those that care about customer experience to improve their software.

Today, I want to share a story about improving performance. We’re always working on performance because the volume of data continues to increase and we constantly have to improve our sub-systems to support that. This issue, however, is a relic of the past.

XDReceiver

Back in the middle ages, when development first began on the world’s best software crash reporting system, cross-domain AJAX calls were a problem.

To work around this, we had a request we’d make to /XDReceiver. All XDReceiver did was return a script block that set the domain:

document.domain=somedomain.com;

Time Moves On

This would be enough to route around the browsers cross-domain checks and make calls from app.raygun.com capable of talking to webapi.raygun.com.

In April, I was reviewing our website performance with Real User Monitoring. I noticed that the XDReceiever calls were not very fast. The reason was that the connection limits to the same domain were saturated, and no caching occurred on the response.

Then, I noticed how frequently that file was called, and it was a lot. After a moment of thinking about it, it makes sense, as every page load in the web app needs to call the API to fetch data.

Raygun’s Real User Monitoring collects all the timing data from every request and gives the average amount of time + the total call count:

Death From a (Hundred) Thousand Cuts

So while the call wasn’t too expensive, it was called a lot. When I multiplied how often it was happening with the amount of time it took to load, it stacked up to a staggering 75 hours of time spent every month just to set up for the cross-domain calls!

Ain’t nobody got time for that.

I asked our team to investigate if there’s a better way.

Who Knew Technology Moves Forward?

One of our team members started looking into how we could do better. As it turns out, we initially put this code in to support Internet Explorer 9! Newer approaches at the time would have meant we couldn’t support IE9, so we’d taken this approach (one we’d borrowed from Facebook).

I likely don’t need to tell you, dear reader, that our audience of software developers aren’t likely to be using an out of date version of IE!

Even Microsoft dropped support for IE9 in January 2016.

Cleaning Up the Code

After finding this, we removed all the XDReceiver related cruft. It touched a lot of places in the code base, so it was glorious to see so much code removed.

In turn, all that is needed by a modern browser is for us to allow the origin to make the call with a cross-origin header:

AddHeader("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");

Much tidier, and faster for our customers. 75 hours faster a month.

Lessons Learned

When most folks think of technical debt, they’re thinking about corners they cut. It wasn’t the case here; it was a relic of the past that we needed to review since time had moved on.

In conclusion, by having comprehensive software monitoring, it became apparent that a significant amount of cumulative time was lost to this call.