Forum / Remote Desktop Manager - Feature Request

reducing reliance on the database

  • Create an Issue
  • Cancel

So try as we might we just can't get the performance of RDM to a level that we would like.
We have even moved the enterprise database to a local SQL express instance here in our office. Even after doing that we still notice the following.

Our office is located in Arizona
Database located in New Jersey
-> average launch time = 13.65 seconds
-> average refresh time = 6.49 seconds

Database located in California
-> average launch time = 9.9 seconds
-> average refresh time = 4.23 seconds

Database located in Arizona
-> average launch time = 7.17 seconds
-> average refresh time = 2.35 seconds

I have a few threads in this forum speaking to the performance of RDM and ways to speed it up. We've determined that the database reliance is the single biggest contributing factor to slowness experiences within RDM. We'd like to find ways to reduce our reliance on the database constantly.
We would like to explore the following set of feature requests. To start, we already know RDM can be set to launch in offline/cached mode. So let's start there.

1) launch RDM in offline/cache mode

2) ability to trickle update the cache from the database on a schedule (once per hour or something configurable)

3) when reconciling the trickle update do a quick refresh of the cache, but this time its done locally so it won't freeze RDM for a few seconds while it updates since the data is already local.

4) ability to read/see properties of entries when in offline mode. We notice that when going to the properties of an entry in offline mode we do not see any of the properties. We understand we can't edit things when in offline mode, but we should still at least see what the properties are. It seems as though RDM does not cache everything about the entries in offline mode. Only the folder structure and names/IP's of the entries.

5) ability to quickly go back into online mode when changing a property of an entry and then back to offline mode after the change has been confirmed. Rather than go to RDM options, switch to online mode, change the entries of the property, then go back to options and go back into offline mode. Perhaps the ability to 'go into online mode' when looking at properties of an entry if it detects you're in offline mode?

6) Even in online mode, when doing manual refreshes from the database we see RDM freeze for a number of seconds while this refresh occurs. (The average refresh numbers from above) Is there a way to not make RDM completely freeze/unusable while this refresh occurs?

7) Our database engineers have determined that RDM is rather inefficient in its usage of SQL database connections. Here is a quote from one of our database admin's about RDM's SQL usage. We would like to get addressed the inefficiencies of RDM's connections to SQL to increase performance.

I did notice that each RDM session appears to hold an open database connection for each target being accessed. For example, three sessions from Scott's RDM client will result in three separate database connections. Connections appear to remain open until the associated RDM session has ended. I would have expected to see one database connection per RDM client, rather than per session. Establishing and opening a new database connection can be a rather expensive process and can take some time to complete. Most applications get around this by maintaining an open connection pool from an application server. If every RDM client session requires a new database connection, this is likely contributing to the delay.

8) We would love the ability to have a complete and 100% cache of the RDM database on each client machine so we're always working with the fastest available storage (our local hard drive). Then only things that NEED to be synchronized to the database can be trickle updated back to SQL. Thinks like audit logs, if properties change it there can be a scheduled background refresh take place every few minutes, etc. We would be fine with this being something that isn't turned on by default. Our database is roughly 300mb on the SQL server. And we would be fine with a local 300mb cache of everything on each client station (though I understand other customers might not want that but since it's not turned on by default they wouldn't be affected)
If this last feature request could be implemented, it would negate the need for features 4 through 7.

Clock14 days

I will create a Epic in our task system. I think it could be good idea but it's an architecture redesign. This will not be possible in a minor update.


David Hervieux


Clock12 days