One large folder vs many small folders

Hi, this is not so much a support question as I am asking for your experience and/or technical background information:
I am using the desktop client on my machines to synchronize all kinds of different types of files: Documents, text notes, and a lot of various savegame files :slight_smile:

As I am currently restructuring my setup anyway, I am wondering about the performance implications of synchronizing a lot of smaller folders vs one big folder (from which things would then be symlinked).
Wondering that I realized that I do not really know how the synchronization works, in particular how it figures out whether something has changed on the server or not. All I know is that having many folders will incur many separate HTTP requests to the Nextcloud server. But it does not look to me as each file checked results in one request, rather that each synchronized folder results in one request. Which would mean that only having one synchronized folder will result in only one HTTP request per sync interval?

In that case, client and server must somehow check whether any of those many files in that synchronized folder has been modified on either side. Does the client transmit the latest modification time of any of those files? Or the result of a hash tree of all the files?

Depending on how this works it could mean that having one large folder to synchronize may be more, less or equally efficient than having multiple folders in network or CPU usage. So, I am just wondering if any of this is the case and if any of you have made some experience with regards to those two methods :smiley:

Symlinks weren’t supported as far as I know, you might want to check that again.

Very large folders can be problematic because the indexing can get very slow if you have many entries (speaking of thousands). Depends a bit on the used file system, but also for the web-view the building of the index from the database will take some time. So I wouldn’t use more than a few hundred objects per folder.

I tried to use a structure where it is easy to select and unselect the folders I want to sync on a specific client, e.g. the mobile computer mostly has just data I’m currently working on.

There are some reports with problems in certain cases, but it’s hard to conclude because the setups are very different and perhaps have configuration issues. Perhaps you find someone who has done some tests on the same setup with different scenarios.

I would symlink the other way around, linking from the “local” filesystem into the folder synchronized with Nextcloud.

My folders are deeply nested, so there aren’t a lot of objects in one folder directly, only if they are enumerated recursively. I suppose the web-view wouldn’t enumerate them recursively, but WebDAV might have to do so I guess? And in that case, having multiple synchronization requests against smaller folders might distribute the load more evenly than having one synchronization request against a large folder?

Do you sync it as one central “Nextcloud” folder and unselect subfolders accordingly (as the client suggests on a new setup), or do you add each Folder you need to work on as a separate “synchronization entry” in the client?

Yes it’s just one large sync folder and I chose the subfolder to sync.

As this is marked as the solution is it really advisable to have one large sync job, or as I suspect, multiple sync jobs each syncing a portion of the larger job.

You can have multiple sync folders. I used that as well on a different account. It gets perhaps a bit difficult, if it is too spread over the filesystem but that is just the human limitation, technically, there shouldn’t be problems.