[Qgis-user] Qgis best practices

[Greg Troxel]

Muki Lukuna | IT Synergy via QGIS-User <qgis-user at lists.osgeo.org>
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