[Qgis-user] Qgis best practices

Muki Lukuna | IT Synergy muki.lukuna at itsynergy.nl
Wed Jan 28 06:55:16 PST 2026


How can i check this? For some reason the exact same file on the exact same virtual machine, worked alot faster at the end of the workday


Muki Lukuna
IT Cloud Engineer @ IT Synergy

[cid:itsfooteremail_e344558a-1941-4773-bd69-a10ea4ce26fc.png]

________________________________
Van: Gert-Jan van der Weijden - GISNederland <gert-jan at gisnederland.nl>
Verzonden: woensdag 28 januari 2026 15:53
Aan: Muki Lukuna | IT Synergy <muki.lukuna at itsynergy.nl>; Muki Lukuna | IT Synergy via QGIS-User <qgis-user at lists.osgeo.org>; qgis-community-team at lists.osgeo.org <qgis-community-team at lists.osgeo.org>
Onderwerp: Re: [Qgis-user] Qgis best practices


Hi Muki,


Could it be the QGis .qgz file has in-meory layers saved into it (through a plug-in like the https://plugins.qgis.org/plugins/MemoryLayerSaver/



regards,


Gert-Jan



On 1/28/2026 12:10 PM, Muki Lukuna | IT Synergy wrote:
SMB Multichannel is indeed active, it is a .qgz file

Muki Lukuna
IT Cloud Engineer @ IT Synergy

[cid:part1.978ZNAek.wL7gq7FZ at gisnederland.nl]

________________________________
Van: QGIS-User <qgis-user-bounces at lists.osgeo.org><mailto:qgis-user-bounces at lists.osgeo.org> namens Gert-Jan van der Weijden - GISNederland via QGIS-User <qgis-user at lists.osgeo.org><mailto:qgis-user at lists.osgeo.org>
Verzonden: woensdag 28 januari 2026 12:02
Aan: Muki Lukuna | IT Synergy via QGIS-User <qgis-user at lists.osgeo.org><mailto:qgis-user at lists.osgeo.org>; qgis-community-team at lists.osgeo.org<mailto:qgis-community-team at lists.osgeo.org> <qgis-community-team at lists.osgeo.org><mailto:qgis-community-team at lists.osgeo.org>
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 <qgis-user at lists.osgeo.org><mailto: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<mailto:QGIS-User at lists.osgeo.org>
> 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
QGIS-User at lists.osgeo.org<mailto:QGIS-User at lists.osgeo.org>
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20260128/bf3c46b3/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itsfooteremail_e344558a-1941-4773-bd69-a10ea4ce26fc.png
Type: image/png
Size: 18639 bytes
Desc: itsfooteremail_e344558a-1941-4773-bd69-a10ea4ce26fc.png
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20260128/bf3c46b3/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itsfooteremail_e344558a-1941-4773-bd69-a10ea4ce26fc.png
Type: image/png
Size: 18639 bytes
Desc: itsfooteremail_e344558a-1941-4773-bd69-a10ea4ce26fc.png
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20260128/bf3c46b3/attachment-0003.png>


More information about the QGIS-User mailing list