NC 20.0.3 - bad performance of the files app

Nextcloud version (eg, 18.0.2): 20.0.3
Operating system and version (eg, Ubuntu 20.04): Linux x86_64
Apache or nginx version (eg, Apache 2.4.25): 2.4.46
PHP version (eg, 7.1): 7.4.11

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 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.

  • Can anyone confirm this behavior?
  • Does anyone know what has changed in the app which could cause the problem?



can confirm in this way:
NC 20.0.2
OS: Linux 4.19.0-13-amd64 x86_64 (VM, NCP)
PHP: 7.3.19

But I thought it was due to heavy network/internet load (am runnig internet via cable… which is a shared medium and there was some performance problems reported, recently)

Unfortunately this seems not to be the problem because I don’t use the mentioned apps on my server. I’ve no checked the list of activated apps and tried to disable all the apps related to files. 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 must admit, that I’m currently mounting 7 WebDAV shares and 1 FTP share but this hasn’t been a problem in past concerning the performance. The Nextcloud log file doesn’t contain any related error message which could shed some light on the root cause of the problem.

Could it be possible that somethng has changed in the handling of external storages?

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 :wink:):

  • 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:

  • Every mounted external file system slows down the load process.
  • The way how external storages are being scanned must have been changed.
  • The way how external viewer functions are being loaded must have been changed.

What do you think @kesselb?

1 Like

Thanks for your debugging :+1: I’m not very familiar with external storages. are the changes from 20.0.2 to 20.0.3. is related to performance in general. Sometimes a wrong database index is picked.

Yes, I already checked the list of changes but it is difficult to find out which effect a change could have on the performance. I think I will create an issue ticket to address the problem. Maybe it raises the awareness that something need to be changed in way how external storages are handled/processed.

Issue ticket:

solved it for me… thanks @kesselb

1 Like