SMB Multichannel is indeed active, it is a .qgz file Muki Lukuna IT Cloud Engineer @ IT Synergy
[cid:itsfooteremail_e344558a-1941-4773-bd69-a10ea4ce26fc.png] ________________________________ Van: QGIS-User <[email protected]> namens Gert-Jan van der Weijden - GISNederland via QGIS-User <[email protected]> Verzonden: woensdag 28 januari 2026 12:02 Aan: Muki Lukuna | IT Synergy via QGIS-User <[email protected]>; [email protected] <[email protected]> Onderwerp: Re: [Qgis-user] Qgis best practices Perhaps Azure Multichannel settings? See https://learn.microsoft.com/en-us/azure/storage/files/smb-performance?tabs=portal<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 <[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<https://lists.osgeo.org/mailman/listinfo/qgis-user> > Unsubscribe: > https://lists.osgeo.org/mailman/listinfo/qgis-user<https://lists.osgeo.org/mailman/listinfo/qgis-user> _______________________________________________ QGIS-User mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-user<https://lists.osgeo.org/mailman/listinfo/qgis-user> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user<https://lists.osgeo.org/mailman/listinfo/qgis-user>
_______________________________________________ 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
