@Starker3 opened this Issue on November 28th 2021 Contributor

Refs L3-181

When loading User ID reports with several thousand rows (For example 3k-10k rows) the report generation in the browser causes very high system resource usage on the device loading the report.

For example an matomo server that has a User ID row limit of 10,000 and selecting the row limit in the UI to "All" takes anywhere from 3-6 minutes (or more) to generate the report in the browser. During this time, that browser tab uses for example 3gb+ of RAM and presents the popup "Browser tab is unresponsive"

If the device being used doesn't have enough spare RAM or just isn't powerful enough to run the javascript to generate the report, that report can basically get stuck for that user and would force them to reset their visualisations to fix it (https://matomo.org/faq/troubleshooting/what-do-i-do-when-the-browser-tab-becomes-unresponsive/).

@tsteur commented on November 28th 2021 Member

I think we're seeing this also in flattened page url reports etc.

We'd want to reproduce this, and then possibly check in what version this regressed if it did regress at all. Or if it's done quicker we could fix it directly.

Below a profile.

Back in the days we had to do column highlihting etc using JS. Not sure if that's still needed now that we don't support certain browsers anymore.

@bx80 commented on November 30th 2021 Contributor

@tsteur I've reproduced this on a local dataset with ~6,800 user ids.

It takes 151 seconds to fully render the user id report using almost 4gb of memory for the browser tab (firefox).
Browser profiling shows that 98 seconds (~65%) of the total time is spent on the dataTable.js::handleColumnHighlighting() method.


To confirm this I added a return statement at the top of the handleColumnHighlighting() method which reduced the total report rendering time to 69 seconds using less than 2gb tab memory.


handleColumnHighlighting() is setting column width (via iterating over rows!) and handling row highlighting with mouseenter and mouseleave events. Disabling the method doesn't appear to make any difference to column highlighting or column widths they are being handled by CSS.

I'll create a PR to remove this method entirely and will do some browser testing with the minimum supported browsers for Matomo v4.6.0

@tsteur commented on November 30th 2021 Member

👍 be good to potentially also check if we can make the ellipsis work with pure CSS (assuming they take also like 30% of the CPU for you) these days but I believe this method by now does a lot more maybe not just to make ellipsis work.

This Issue was closed on January 4th 2022
Powered by GitHub Issue Mirror