Bad performance of the files app when accessing external file systems

[j-ed]

Current behavior

I’ve just updated my server from Nextcloud v20.0.2 to v20.0.3 which works without any problems. After I’ve logged in to the server again I realized a really bad performance of the files app. Loading the initial list of folders lasts around 18-19 seconds now compared to 2-3 seconds before. Navigating through sub directories is still working with the same performance as before. All other apps are also still working with the expected performance except the files app.

I’ve checked the list of activated apps and tried to disable all the apps related to file handling. I found out that the Files_external app seems to be responsible for the slow loading of the files app. As soon as I deactivated the app, the general performance was back to normal.

I’m currently mounting 7 personal WebDAV shares from a NAS and 1 personal FTP share, which hasn’t been a problem in past concerning the performance. The Nextcloud log file doesn’t contain any related error message which might shed some light on the root cause of the problem. So I ran further tests of the Files_external app by removing all external shares and re-adding them one-by-one. Here are the results (time measured manually 😉):

• Open app without any mounts: 3s
• Added 1. WebDAV share: 4s (+1s)
• Added 2. WebDAV share: 4,45s (+0,45s)
• Added 3. WebDAV share: (containing pictures): 5,45s (+1s)
• Added 4. WebDAV share (containing e-books): 9s (+3,55s)
• Added 5. WebDAV share (containing music): 13s (+4s)
• Added 6. WebDAV share (containing notes): 15s (+2s)
• Added 7. WebDAV share: 17s (+2s)
• Added 8. FTP share: 18,75s (+1,75s)

Due to the fact that mounting the WebDAV share which contains e-books, increases the load time by 3,55 seconds, I disabled the EPUB/CBZ/PDF ebook reader app v1.4.5 which had the following effect on the result:

• Disabled the epubreader app: 15.75s (-3s)

Due to the fact that mounting the WebDAV share which contains music, increases the load time by 4 seconds, I disabled the Audio Player app v1.4.5 which had the following effect on the result:

• Disabled the audioplayer app: 15s (-0,75s)

My conclusions about what is happening on opening the files app:

1. Every mounted external file system slows down the load process.
2. The way how external storages are being scanned must have been changed somehow.
3. The way how external viewer functions/apps are being loaded must have been changed.

Link to the thread in the Nextcloud help forum: https://help.nextcloud.com/t/nc-20-0-3-bad-performance-of-the-files-app/100782

Environment

Server Configuration

OS: Linux 4.9.220
Web server: Apache2 2.4.46
Database: MariaDB 10.2.24
PHP version: 7.4.11
Nextcloud version: 20.0.3

Client Configuration

Browser: Mozilla Firefox 83.0
Operating system: Windows 10

[jakeh999]

I am also able to reproduce the slowdown under NC 19.0.6.

[codingHahn]

I can also reproduce this with an big (1.8 TB) external Nextcloud share. The folder I move this share into slows down to ~20 sec load time. Folders without this share load in under 1 sec.

[szaimen]

I suppose this is still valid on NC21.0.2?

[j-ed]

Yes, loading of my Nextcloud root which contains 13 folders still lasts 13 seconds on NC 21.0.2.

[Fabyao]

We have installed a new instance of NC21.0.2 on a VPS with 16Gb, 6 CPU and SSD disk. The user experience is poor and feels sluggish. Navigating between pages take few seconds to load. On average between 3 to 10 seconds. This is with redis cache for both "distributed" and "locking". For "Local" caching, we use "APCu". There seem to be numerous report of performance issues. As we are new to Nexcloud, we dont have previous metrics to compare with version 21.0.2. What is the "accepted" page loading time? Is 3 to 10 seconds loading time expected with NextCloud? Thanks

[szaimen]

Hi, please update to 24.0.9 or better 25.0.3 and report back if it fixes the issue. Thank you!

My goal is to add a label like e.g. 25-feedback to this ticket of an up-to-date major Nextcloud version where the bug could be reproduced. However this is not going to work without your help. So thanks for all your effort!

If you don't manage to reproduce the issue in time and the issue gets closed but you can reproduce the issue afterwards, feel free to create a new bug report with up-to-date information by following this link: https://github.com/nextcloud/server/issues/new?assignees=&labels=bug%2C0.+Needs+triage&template=BUG_REPORT.yml&title=%5BBug%5D%3A+