So this is interesting. It seems that it could have something to do with deck.
So we use deck a lot, and we have like a couple thousand cards with attachments.
If delete everything from it, it work fine.
Still investigating.
Oddly I have this issue randomly as of a week ago but only with one user. Debugging and will add notes if I find something to check.
So far 'db_persistent' => true,, maintenance:repair, files:scan, etc. etc. have not fixed the issue with just this one user (happens to be me so while annoying, at least it’s just me.)
Tasks, deck, etc. are perfectly fine though. It’s just files and notes (which uses files so unsurprising.)
My user does have external federated shares which I’m looking into and a lot of old entries in oc_storages table. I don’t know if it’s possible to remove those entries from the db and from oc_filecache (or if the latter updates on the next files:scan run anyhow) as I have not checked the schema yet to know if it provides foreign_key for any other table.
As for the dev tools, it seems calls made to remote.php/dav are slow along with “stats” which is on the files/api/v1 path. Proxy is correctly configured and shows no errors. After about 20 seconds, it loads it all up and then is just fine. Can’t really place it.
Apologies for half derailing the thread but hoping we can help each other out and fix both.
Edit- removing the one federated share may have helped a little and setting 'davstorage.request_timeout' => 10 didn’t seem to make much difference.
Edit- solved my issue below for anyone finding this later on.
Ok, I figured out my issue with the Files app so hopefully it helps OP or someone else in the future.
List of things tried with minimal/no impact:
config.php
- dbpersistent=true
- davstorage.request_timeout => 10
- disabled file previews
Others (gui)
- disabled federation
- disabled text
- disabled file reminders
- raised php limit to 1G (using docker so the stock 512M in my use case should be fine honestly and was for other users)
Thing that actually worked:
- Friend that has federated with me before shared some folders out and I left them.
I noticed a slight increase in speed after leaving the one share. I did not notice he had long ago shared one more thing with me.
Since he just stood up a new server, I think I was trying to federate with it again and it was timing out/taking forever for whatever reason. I started to very much notice when I was entering one specific folder that didn’t appear snappy as the rest (the first share was in my root, the second was in a subfolder which appeared slow.) That explained why the initial load was slow and why the opening of the one subfolder with the share in it was slow but the rest were not (to include NFS/external shares, etc.)
Leaving both shares fixed my issue. Things are snappy again, etc.
OP- maybe check if some shares are timing out? I don’t know of an “easy” way to do that without either leaving them or disabling federation and file sharing entirely (which is not easy either.)
This is not what was causing my problems. So i still dont know what actually is happening in detail. And im saying this because i did not debug the actual code that was being executed.
Having that said, i did find out (mostly) what is happening.
So we are using the Deck app every day, and we have a few boards that have quite a lot of cards. So the total number of cards is around 5000-6000 and most of them have file attachments.
So after looking at the database i saw that nextcloud actually makes a share for each attachment of each file of each cards for each user that has access that board.
So if i have 3 files for each card, and i have 1000 cards, and 20 users on that board, that means 60000 shares.
What i ended up doing is export the data of the older cards, and delete them, and now it works a bit better. It still take a while to load, but now as long.
We will switch to another, separate kanban board, and now use Deck, as it does not seem to be able to handle so many files
EDIT: so can anyone confirm that this is what deck is doing with the attachments ?