Go to All Forums

Improve RUM: Add caching information

I hope you will consider adding caching details to RUM reporting.

  • Share of cacheable and non-cacheable resources
  • Cached vs uncached resources
  • Resource download size? How else would I know how performance is? Timing alone is not enough, is it?
  • Improved resources reporting, enabling exploration of requests and headers
  • Use filtering/segments such as device type. There's a Device Type report, but it's very basic
  • Page groups and filtering
  • Recordings, maybe? Snapshots are near useless
  • Javascript warnings?

In general I'd say this:

Site24x7 RUM should enable us to pinpoint areas of improvement, issues and report on improvements. It doesn't live up to that.

 

Adding a bit more to the feature request by quoting blogs.akamai.com/2015/12/cdns-performance-and-monitoring---part-2.html

Now let us look at the KPIs from your front end (RUM) monitoring:

  • Performance affected by various factors - load time across various dimensions
    • By page - how long each web page took to render on the browser
    • By mobile devices - on mobile you have less bandwidth, are pages smaller?
    • By various browsers
    • By geography
    • By Edge cache hit or cache miss  (might require integration with your CDN metrics)
  • Error frequency and types of errors, by page
  • Performance of various steps in the browser's functionality
    • Download time - how long did it take the browser to suck in all the content
    • DOM time - once data is sucked in, how long to parse and build the parse tree
    • Render time - once all the data was read in and parsed, how long to actually render it
  • Size of content - ensure pages are not too heavy

 

Quoting another site:

Benefits of RUM

RUM can help identify how page visitors are using a site or app. It also provides page metrics such as load time for analysis of a page, objects and even individual visits.

  • Measure service level targets easily. It offers real-world measurement of key targets by tracking actual visits and delivering top-level data on actual use cases.
  • Easily identify problems and better prioritize issues. It can replay user sessions and track transaction paths to surface hidden problems.
  • Determine hitches at the network and page level. Problems at the lower levels of a website can hide like needles in a haystack. It can spotlight these problems even when they’re intermittent in nature or based on rare conditions.

 

Like (2) Reply
Replies (1)

Re: Improve RUM: Add caching information

by Jay1

Hi Allan,

Thanks for your detailed briefing regarding your requirements. 

We would like to convey a few points regarding the feasibility of the requested 

 

"Share of cacheable and non-cacheable resources" and "Cached vs uncached resources"

 

It is not possible to capture these in a straight forward manner. This information is available from the headers of the request and it is not possible to fetch the headers of already loaded pages or resources unless we make another request and capture the headers. Nevertheless, if there is a way to capture these, we will definitely add this to our roadmap and update the same here.

 

 

 

>Resource download size? How else would I know how performance is? Timing alone is not enough, is it?

 

We are working on adding the resources download size and page size along with the response times and we will update the same here once it goes live.

 

 

>Improved resources reporting, enabling exploration of requests and headers

 

It is not possible to report all the resource requests as there will be hundreds of different resources loaded in an application and hence these are filtered by domains and shown in the Resources tab. As we have mentioned earlier it is not straightforwardly possible to fetch request headers of the loaded resources but we will look into the possibility of capturing these.

 

>Use filtering/segments such as device type. There's a Device Type report, but it's very basic, Page groups and filtering

 

It will be helpful if you could elaborate on your requirements regarding this. If you are asking about the webpages filtering by location, device and browser, we are already working on to provide the option and we will update here once we release.

 

By default we do group dynamic urls in to a single url. For example you have /webpageurl/13t3sjsydd48dh/ and /webpageurl/udjdh838d3d/, we capture these and show it as /webpageurl/*/.

 

>Recordings, maybe? Snapshots are near useless

 

Snapshots do show the user navigation path by browser and location. Performance metrics for each page like its response time, resource load time etc. are also shown. However we do accept that recordings will be even more insightful, so we will check the feasibility and number of such feature requests and add it to our roadmap.

 

>Javascript warnings?

These are also not straightforwardly possible to fetch as it is a browser functionality and it appears in the console. We will look into the feasibility of intercepting the console API of browser and try to fetch these.

 

>In the section "Performance affected by various factors", we do have all the metrics you have mentioned there. 

We do show the CDN metrics filtered by domains in the Resources tab in RUM client. Aggregated CDN requests are one thing we are working on.

 

We also show error frequency and types along with browsers and device types in javascript errors tab.

 

 

All the Performance metrics at various steps in the browser's functionality like the connection time, DNS time, backend time(server time), firstbyte time, download time, document load time, page rendering time are captured for every page request and are available.

 

 

We also have RUM traceroute where you can identify the network path a request took to get to your website, and every hop made in between. This helps you to identify whether requests experienced any interruptions reaching your website. For details, you can refer https://www.site24x7.com/help/apm/rum/rum-traceroute.html

 

 Regards

Jaya Simha

APM Insight-RUM

 

 

Like (0) Reply