+3
Completed

Access page freezes when there are a lot of access sessions populating

Leah Jennings 4 years ago updated by Russell 2 years ago 5

We have 6400 access sessions with an access session group called "All Machines". That's the group we're in most often because it is easy to search for the machine you need, however if you don't search quick enough the whole Access page freezes and you can't click anything because it hangs on populating that many machines. Once the sessions populate, the page is horribly slow. If I click on another access session group with fewer machines (like 50), I see the URL update to the right group, but the page is still frozen. That's in Chrome. The same behavior is in IE, but it's not as sluggish after all the access sessions populate. FireFox behaves the same way, and is a little better than Chrome after the sessions populate but still more sluggish than IE. Would love to see some performance improvements so we aren't quickly trying to search before the page gets hung.


Effected browsers:

Chrome 57.0.2987.110 64-bit

IE 11.953.14393.0

FireFox 52.0 32-bit


OS I'm accessing SC from: Windows 10 Anniversary Edition

This is also an on-prem version of SC. Our version of SC is currently 6.0.11622, but this has always been an issue.

Available in Version:

Answer

Answer
Completed

Implemented performance improvements in 6.3 so loading is 4x faster. We're also planning out other web application and client performance improvements for the future. 

Waiting for information

Good afternoon,


When you first navigate to the All Machines session group containing 6400 machines, the server returns detailed information about every session in that group (this includes the session name, custom property values, and guest machine attributes for all 6400 machines). Furthermore, whenever a session in the All Machines group is altered (custom property change, host joined, etc), the page makes a call to retrieve the updated session info. Your browser is very likely having trouble processing information for all 6400 sessions (as noted, different browsers process page information differently, hence the performance differential among browsers).


If it's not too much trouble, could you update this thread with your on-prem server specs, including OS, CPU, and memory resources? I will likely move this thread over to our feature request portal so that our product management team can review the information related to your performance improvement request.


Regards,

Ben

Thanks Ben! Below are the specs of the on-prem server.


OS: Windows Server 2012 R2 Standard

CPU: 2 sockets, 4 virtual processors, Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz

RAM: 10 GB

It's a virtual server and is dedicated to running the ScreenConnect application, so no other applications are running alongside it.


Under Review
Answer
Completed

Implemented performance improvements in 6.3 so loading is 4x faster. We're also planning out other web application and client performance improvements for the future. 

+1

How about adding pagination to the third column of the Access pane where all the sessions are listed?