Web UI memory leak - DOM nodes and

michael.obrien 3 years ago updated by Cody Arnold 3 years ago 16

My CW Control tab (in 6.1 and 6.2 series at least, not sure about before) uses a massive amount of memory, tested in Chrome, FF and Edge. It looks like the JS heap is fairly stable @ 10 - 20MB, but DOM nodes and event listeners balloon massively over time - about 10 minutes in, I see 70k or so of each and they just keep growing.

I have a JSON Chrome debugger timeline dump - don't see how to attach it here, but e-mail me if you'd like it.

About 1,500 access hosts total, running on Server 2012 R2 with SQL backend.

ConnectWise Control Version:
Server Affected:
Host Client Affected:
Guest Client Affected:

Whoops, title should be DOM nodes and event listeners.

Waiting for information

Good morning Michael,

I've begun looking into your report and support passed on your timeline dump.

I understand you're concerned about the growing number of DOM nodes and event listeners on your ConnectWise Control site. If you don't mind, can you update this thread with a list of extensions you've enabled on your instance of Control?

Also, during the 10 minutes when you recorded the timeline in Chrome, how actively were you using your site?

I profiled my dev instance of Control for ~10 minutes (with 30+ extensions installed), and found that the number of nodes and listeners were relatively stable over that timeframe: Nodes/listeners increased for the first ~7 minutes or so and peaked at approx 3300 nodes and 1800 listeners, and then dropped to approx 1400 nodes and 1000 listeners shortly thereafter:



No extensions enabled.

Medium activity I'd say, maybe a few sessions open. Other techs had sessions open I'm sure.

Note - we have about 1500 access sessions and about 100 session groups.

Also worth mentioning, when the tab gets up to 1M DOM objects and event listeners Chrome (and other browsers) get REALLY sluggish :)

Any luck with the review / investigation?

Good afternoon,

This issue has been registered with development and is currently under investigation. While I don't have a definitive update at this time, development is investigating the underlying cause of performance degradation on the host page for 6.2 instances as compared to earlier versions of ConnectWise Control.



I experience a similar issue.

However I've had over 2-3k access sessions since version 5.5 and it seems like after maybe 6.1 it became an issue I'd have to go back and see when I upgraded.

That being said I've done some testing with support tonight, after rebuilding SC db & testing diff groups. If I use a group with 305 access sessions in it, it runs like a dream. with 1550, it definitely has degraded performance but is kinda usable.

If I load all 2700(At this time only 2700 of 4000 have repopulated in the DB since rebuild) you might as well not even try.

As a workaround I just click all sessions and try to fit in a search before it loads the page and thats been my workaround for now.

Our problem is slightly different, in that we have small groups (max 150, but mostly around 20 - 50). Even when working in a small group, memory usage ballons. I'm not sure how SC's frontend works, but the background datastore seems to be more a problem than DOM rendering (provided everything doesn't live in the DOM all the time, which I'm not inclined to dig into until the SC team has dug into this further).

Still worth noting just in case it is somewhat related they may be able to reach out and get some additional info.

I've not really noticed abnormal memory usage, however there has been times where the issue will cause my entire PC to be unusable just from loading the SC webpage, Where I've had to reboot, yet task manager showed no abnormal resource usage which didn't make sense. And it's happened in Chrome and or Firefox.


Completely agree worth noting!

Good day,

I want to thank all of you for providing a detailed account of your host page performance issues. We are continuing to narrow down the root cause of the host page performance bottleneck, and are finding that it may be related to page rendering/styling based on a number of Chrome performance timeline recordings. The issue is clearly exacerbated when working out of larger session groups, e.g. All Machines.

I will update this thread as more information becomes available.



I spoke with someone a couple days ago from support and apparently these issues are slated to be fixed in the 6.3 update.