Waiting for information

Performance Issues When Using Remote System Diagnostics Extension

Matthew Swanson 5 years ago updated 5 years ago 6

When using the Remote System Diagnostic Extension, published by ScreenConnect labs, under both 6.0 and 6.1, we were experiencing significant performance issues. The main panel would take 30-90 seconds to fill in, and session information was similarly delayed. This problem progressively got worse over a period of time. Resources on the box were not an issue.

We are also running on MSSQL, so support essentially washed their hands and blamed the flavor of SQL as the reason for the problem without doing any more troubleshooting than saying the circle was spinning so the issue was SQL.

After disabling the extension and purging all entries in SessionConnectionEvent where EventType=83 (p.s. the documentation on the support site still does not define this event, but it looked like diagnostic data when I reviewed the DB), performance returned to normal. In our case, we purged ~600,000 entries of this event type.

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

Correction - published by ConnectWise Labs. I didn't know if the extension is written by the same dev team or if there is a better place to provide the feedback, but it definitely appears to be the culprit of the performance problems we've been fighting with.

Good morning Matthew,

Thank you for reporting this information. While we don't officially support database engines other than stock SQLite, I am happy to hear that removing CopiedFiles events (EventType = 83) from your MSSQL database resolved the performance issue.

As a note, the Remote System Diagnostics extension does not write copied files events to the database (it would, however, add QueuedCommand events, type 44) -- can you confirm that re-enabling the Remote System Diagnostics extension does not degrade performance now that you've removed the preponderance of copied files events from your database?



Waiting for information

I can confirm that this is not related to the extension as I originally suspected. I do, however, believe there is another bug somewhere. We've had several performance issues over the past two weeks. Today, our installation became non-responsive again.

Upon investigation, we discovered there were 425,391 records of the type 83 in SessionConnectionEvent. Upon purging these records again, the system became responsive again and the errors resolved.

We are going to try creating a scheduled job that runs this command on a daily basis in order to prevent recurrance of this issue.


FROM SessionConnectionEvent
WHERE (EventType = '83') AND (Time > DATEADD(dd, - 30, GETDATE()))

Good morning,

That is a very large number of CopiedFiles events. A few thoughts:

1) I would be interested in knowing how performance of the stock implementation of SQLite compares to MSSQL. Version 6.1 included some changes to optimize database performance, particularly for instances with larger databases.

2) What sort of resources have you allocated to your ConnectWise Control server? Since the operation is timing out, this leads me to believe that the server may be under-powered, CPU and/or memory-wise, for the amount of activity it's handling.

3) Version 6.2 implements more granular control over database maintenance actions; for instance, assuming the preponderance of CopiedFiles events are associated with guest access session connections, you will be able to define a maintenance plan action that deletes guest access session connections older than X days (this also removes associated session connection events from the database). Defining an action such as this should ensure your database does not become overwhelmed by a certain type of session connection event. While I wouldn't recommend upgrading a production server to the 6.2 pre-release, a stable build of 6.2 should be available within a month or so.



I was surprised by the number of records, too. We use very few access sessions, but typically have 800-1000 open support sessions (only several hundred of them are active at any given time).

1. I'm not sure how to test this scenario.

2. I don't think it is an overall resource issue. The Windows environment remains responsive. We've allocated 21 GB RAM and 8 cores. SQL continues to be responsive. When tracing the query, I've found each of the queries responds well under 1 second as it iterates through the list of sessions, but cumulatively, with the number of support sessions, and the design that seems to return all session details of all sessions before displaying the list, it must cause the timeout.

3. I'll look at the built in DB maintenance in 6.2 - I have the Focus Group build installed in a lab. I would suspect that this would accomplish the same thing as my SQL agent job that is purging the specific records, too.