0 vote
Good morning.
A little background:
We have 2 vaults.
The main one has around 3200 entries.
The second one has 55 entires.
More serperation of vaults is unfortunately not an option for us.
We are using SSH Tunnels with private key authentication (brilliant feature imo, especially multihopping)
We would need to create / copy those entries in every vault. When we cycle keys, that would mean alot of work.
We have enabled a feature called "Force refresh before edit entry".
Disabling this feature unfortunately is not an option, because multiple users work on objects, thus overwriting stuff of eachother.
In the vault of 3500, Every time we want to do right click / properties on a object (doesn't mater which one), we have to wait for like 15 seconds before we get the properties window presented.
The vault of 55 entries takes about 4 seconds (which still is a long time, considering 55 entries)
in short, it seems that Remote Desktop Manager, always, fetches the whole database, or, pushes the whole database when making edits.
Wouldn't it be a good idea to optimize queries. like, only fetching the data needed. Then people could have a million records, and performance still would be good. Options like "Force refresh before edit entry" wouldn't be needed then as well i think.
I can imagine that would be alot of work. Perhaps even start from scratch in some areas...
but, the usability of this product would increase by alot, and would scale alot better.
Something odd is going on somewhere (local, network, settings/options). This is not normal we aim to have all/most actions respond sub-second so anything over that is not normal.
To start a few questions:
Best regards,
Stéfane Lavergne
Hello, thank you for your answer :)
Our datasource is Devolutions server 2022.1.7.0
We have caching completely disabled, as per recommendation we had with a previous case.
basically, when alot of people change passwords, stuff doesn't work because people connect with old passwords, and also overwrite issues etc with password lists.
If you're wondering: it's case: 00002163
I have sent the profiler log :)
Thank you for your time :)
Thanks, I had a quick look at the profiler trace. Since caching is disabled RDM must fetch, as you suspected, all entries with every refresh. With "Intelligent" caching enabled we only fetch the delta of changes (add/edit/deletes) so that a refresh is much faster.
You will need to enable caching. Caching with "Force Refresh" should prevent any issues with users overwriting other users edits. No need to enable offline in this case but caching is a must.
File > Data Sources > Edit > Advanced > Caching Mode => Set it to "Intelligent"
We have caching completely disabled, as per recommendation we had with a previous case.
basically, when alot of people change passwords, stuff doesn't work because people connect with old passwords, and also overwrite issues etc with password lists.
With caching enabled a refresh prior to fetching a password should resolve the issue. A simple F5 (or refresh icon) or even auto-refresh enabled should resolve most if not all your issues.
Side note: we should probably add an option "Force refresh before copy username/password" that does the exact same thing as the "Force refresh before edit" but for reading values out of an entry. This will completely resolve your issues since now users won't have to refresh manually.
Best regards,
Stéfane Lavergne
With intelligent caching enabled, properties open up almost instantly. Thank you!
i'd say, an option "force refresh before copy username/password" but also "refresh on connect" would be a nice addition.
We've added new Refresh before... flags with the upcoming major release (v2022.2), out in beta soon. You will need both RDM v2022.2 & DVLS v2022.2 for this to work.
Note: that Refresh before edit entry already existed (and still exists) in System > Options. Since this is not as easy for administrators to push changes out to everyone, we move them to System Settings so that an admin can force Refresh before... with every utilization of that datasource.
You can also use the corresponding Policy to enable the refreshes.
Note: We allow to enable Refresh before... even if caching is disabled. This is not recommended as performance will take a major hit.
Stéfane Lavergne