DZone
Performance Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Performance Zone > Saving Customers 75 Hours per Month With Real User Monitoring

Saving Customers 75 Hours per Month With Real User Monitoring

By using real user monitoring, one company drastically improved the performance of their web app. Read on to get their story.

Freyja Spaven user avatar by
Freyja Spaven
·
Oct. 26, 17 · Performance Zone · Analysis
Like (2)
Save
Tweet
3.34K Views

Join the DZone community and get the full member experience.

Join For Free

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:

Website performance timing data

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.

Real user monitoring

Published at DZone with permission of Freyja Spaven, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Password Authentication: How to Correctly Do It
  • What Is URL Rewriting? | Java Servlets
  • Don't Underestimate Documentation
  • Java Hashtable, HashMap, ConcurrentHashMap: Performance Impact

Comments

Performance Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo