[Bug]: Slow query getMountsForStorageId when user has many shared folders

Ivansss commented 1 week ago

⚠️ This issue respects the following points: ⚠️

[x] This is a bug, not a question or a configuration/webserver/proxy issue.
[x] This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
[x] Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
[x] I agree to follow Nextcloud's Code of Conduct.

Bug description

Detected the issue in the following scenario:

User A has 40K+ shared folders User A share one of those folders with User B User B experiences slowness because it has to cope with the 40K+ mount points

https://github.com/nextcloud/server/blob/8995272f60b7d30c58565aa0eeb01e39f3629644/apps/files_sharing/lib/SharedStorage.php#L443-L444

The query was triggered by "Text" app's rich workspaces:

Expected behavior

User B should not experience that slowness when loading its files

oleksandr-nc commented 1 week ago

Detected the issue in the following scenario:

User A has 40K+ shared folders User A share one of those folders with User B User B experiences slowness because it has to cope with the 40K+ mount points

We have the same scenario, only in it disabling "rich workspaces" does not help in that case.

icewind1991 commented 4 days ago

Having it such that loading the share for userB doesn't require setting up all the shares for userA would require a significant rework in how the filesystem is setup.

icewind1991 commented 23 hours ago

Looking at things again, this specific code path (via getWatcher) can maybe be improved. But I don't know how much that fixes the overall performance in a setup like this.

icewind1991 commented 23 hours ago

https://github.com/nextcloud/server/pull/49569

nextcloud / server