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.
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.
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.
The option is AlwaysEndSessionOnExit, but it isn't implemented until 6.1, which I think is still in controlled relaease.
We requested this some time ago. 6.1 includes the option to force the session to end when the hosts disconnect so that they can't be left open. This is an acceptable approach for us, and we'll be implementing it, although what is talked about here, where the session is ended after XX seconds that the host has disconnected (to keep the hosts from coming back later without explicit permission), would be a preerable implementation.
it would be great if this feature included a maximum number of installs per URL.
For example, with LogMeIn, when you create an install URL, you can set an expiration date as well as a maximum number of installs from the link, which is useful when keeping the link from being distributed wider than planned and installed on more machines than planned.
I'd also like to capture a log on the client side, but for a different reason - if the client wants to audit when the last time we were conencted, I'd like them to have the visibility without me needing to search for it on the server side.
Customer support service by UserEcho