Extremely poor performance when exporting / importing XML via Powershell

Hi Kia,

Thank you for reaching out and for your patience.

I have started working on this and will keep you updated on my results before the end of the day.

I mainly wanted to let you know that this is being looked into.

Best regards,

Hi Kia,

You mentioned your RDM version, but not your DVLS version. Could you let me know which one you are using? For reference, I am testing on DVLS 2025.2.12.

Based on my tests, this behaviour does not appear to be limited to the PowerShell module or specifically to the Export-RDMSession -XML command.

Out of curiosity, if you use the export feature in RDM to export your template vault as a .rdm file, do you see the query "SELECT * FROM dbo.Connections WHERE Version > @Version" occurring just as often?
https://docs.devolutions.net/rdm/commands/file/export/#export-vault-rdm-windows

My impression is you'll likely see just as many read/write operations.

I recently had a meeting with another customer who also reported this query frequently appearing in the list of expensive queries. In their case, it was mainly due to the high number of concurrent users on the solution. The development team is planning improvements to caching and indexing in DVLS, and this specific query is one of those being targeted.

Since your use case is slightly different, I will confirm with the team tomorrow whether the upcoming fix might also improve the behaviour you are experiencing.

Best regards,

Hey Marc,

> Out of curiosity, if you use the export feature in RDM to export your template vault as a .rdm file, do you see the query "SELECT * FROM dbo.Connections WHERE Version > @Version" occurring just as often?

Yes.

> In their case, it was mainly due to the high number of concurrent users on the solution

Sounds like this could also be the case for us. We also have a high number of concurrent users.

fyi, I was able to cut down the import time from 15 minutes to 5 minutes, by chunking the exported .rdm file in such a way, that I am importing empty folders first and then only the connections. My guess is that switching between those operations is time-intensive when doing a regular import, which is why it takes longer.

Hi Kia,

Thank you for the information.

Can you run the following SQL query:

UPDATE STATISTICS dbo.Connections IX_Connections_Version WITH FULLSCAN

This should help performance by reindexing the Connections table.

Once done, can you let us know if you see an improvement in the SSMS "Recent Expensive Queries"?

Thank you!

Best regards,

Hey Marc,

After executing the command and running another migration attempt, it no longer appears in the Recent Expensive Queries.

We are okay with the performance now, but have gotten reports that 1-2 hours after starting to import (total runtime is 4-5 hours at this point) users sometimes don't see any repositories. I assume the server is too busy processing the imports that user requests time out or something similar. The issue resolved itself after 10 minutes (we did not stop importing).

Do we need to add pauses between each import?

Hi Kia,

Excellent, glad the reindexing helped.

• Do the users get any visible error codes you could share with me?
• Can you enable the DPS_Main logs and check if there are timeouts? Here’s how: https://docs.devolutions.net/server/kb/how-to-articles/enable-server-log4net-log/
• Once users report that they can’t see the repositories, what happens if you reset the server cache?: https://docs.devolutions.net/server/web-interface/administration/security-management/reset-server-cache/

Feel free to send me the logs in a private message so I can review them.

Best regards,