[Qgis-user] Qgis best practices

Wed Jan 28 03:02:13 PST 2026

Perhaps Azure Multichannel settings?
See 
https://learn.microsoft.com/en-us/azure/storage/files/smb-performance?tabs=portal

Apart from that: what kind of file is the 2 Mb file?
A QQis project file (.qgz), or a geopackage (.gpkg, which is a sqlite 
under the hood), or a file geodatabase (.fgb, which is under the hood a 
large number of files, probably zipped together)

regards,

Gert-Jan

On 1/27/2026 2:48 PM, Greg Troxel via QGIS-User wrote:
> 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
> _______________________________________________
> QGIS-User mailing list
> QGIS-User at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user