Muki Lukuna | IT Synergy via QGIS-User <[email protected]> writes:
> I work for an MSP and we manage IT for a client that recently migrated from > an on-prem environment (RDS + file server in > the same rack) to Azure Virtual Desktop. Since the migration, QGIS > performance has degraded when opening and saving > certain datasets/projects. I hope this move turns out to be a good idea! What was the performance experience when you configured and tested the setup in staging before committing to the migration? > Environment > > * QGIS version: 3.40.12 “Bratislava” > * Azure Virtual Desktop (multiple session hosts) > * Data stored on Azure Files / Storage Account (Premium), same region as AVD > * Access via Private Endpoint (no public internet path to the storage) > * First days after migration were OK, issues became noticeable after a few > days Many of us know nothing about Azure, but I'm going to guess this is just CIFS. > Symptoms > > * Opening and saving files is slow and sometimes appears to hang > * For one specific dataset/project, QGIS crashes on open or on save > * Windows Explorer also becomes “Not responding” when opening/saving that > same file set (seems I/O related) > * Other files can also feel slower, but the reported file is consistently > problematic > * The file that seems to hang the most is a 2 mb file If Windows Explorer is hanging that is a very strong clue that you have infrastructure problems and this is no a qgis issue. In 2026, 2 MB is not a big file. Just as a not-your-environment test, I found a 2 MB file on an NFS server (NetBDSD) on a not-particularly fast client (Raspberry Pi 4, NetBSD), connected via GbE, and ran sha1 to checksum it. The first time was 386 ms, the second was 31 ms, and the third a few minutes later was also 31 ms. I conclude that it took about 350 ms to fetch the file. Your report is not quantitative, just saying "slow", and with "hang" you didn't say how long you waited (or if other file accesses were ok in that time frame). But I'm pretty sure you're not complaining about opening a dataset taking 350 ms to fetch and another second to process. > What we are looking for > > * Are there known QGIS settings, data formats, provider options, or project > configurations that can cause heavy file > locking / long blocking I/O over network storage? > * Any recommended best practices for running QGIS in a VDI/remote desktop > setup with data stored on network file shares > (Azure Files), especially regarding caching, temp directories, or avoiding > certain workflows? > * Any logging or diagnostics you recommend (QGIS logs, GDAL/OGR debug > options, crash dump locations) that would help > narrow down whether this is QGIS-related vs storage/SMB/locking/latency? Best practice is not to store data over CIFS. I would suggest using postgresql/postgis instead. Overall, you seem to be having a network filesystem problem. Many people use QGIS over CIFS and have only the moderate trouble of not having reasonable multi-user access. That isn't a proof that there isn't a qgis problem, but it's a clue. It seems obvious that you should be running fileystem tests and benchmarks on the infrastructure without qgis, and only when that seems to have great performance worry about qgis. With desktops and servers all in the same cloud region, performance should be excellent. To help others (as you are asking for peer help within a community), please post the results of benchmarks, and the eventual resolution. Greg _______________________________________________ QGIS-User mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
