Nextcloud Web UI EXTREMELY Slow

Support intro

Sorry to hear you’re facing problems :slightly_frowning_face: is for home/non-enterprise users. If you’re running a business, paid support can be accessed via where we can ensure your business keeps running smoothly.

In order to help you as quickly as possible, before clicking Create Topic please provide as much of the below as you can. Feel free to use a pastebin service for logs, otherwise either indent short log examples with four spaces:


Or for longer, use three backticks above and below the code snippet:


Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can :heart:

Nextcloud version (eg, 20.0.5): 23.0.2-fpm-alpine
Operating system and version (eg, Ubuntu 20.04):

PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION="10 (buster)"

Apache or nginx version (eg, Apache 2.4.25): nextcloud-nginx-unprivileged:alpine
PHP version (eg, 7.4): 8.0-fpm-alpine3.15

The issue you are facing:

I set up a new Nextcloud instance by using the official Helm Chart. Before migrating the data from my previous installation, the new installation is already extremely slow. I mean, not like 10 seconds waiting time slow.

I mean like seriously at least 30 seconds, for each mouse click (I measured it with a stopwatch). Sometimes up to a minute or even longer.

Is this the first time you’ve seen this error? (Y/N):
Yes and no. The old installation was not smooth. It was slow compared to other server apps. Nextcloud is so big, it might be slower, than others, I thought. It was bearable, though.

However, now it became absolutely unbearable. It’s currently in an unusable state, even though I can access everything, in theory.

Steps to replicate it:

Install the official Nextcloud Helm Chart.

The output of your Nextcloud log in Admin > Logging:
Upload of a screenshot failed.

It shows a lot of errors of the following kind:

OCP\Files\StorageInvalidException: Sabre\HTTP\ClientHttpException: Unauthorized

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

$CONFIG = array (
  'htaccess.RewriteBase' => '/',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'apps_paths' =>
  array (
    0 =>
    array (
      'path' => '/var/www/html/apps',
      'url' => '/apps',
      'writable' => false,
    1 =>
    array (
      'path' => '/var/www/html/custom_apps',
      'url' => '/custom_apps',
      'writable' => true,
  'trusted_domains' =>
  array (
    0 => 'localhost',
    # main URL
    2 => '',
    3 => '',
  'forwarded_for_headers' =>
  array (
  'app_install_overwrite' =>
  array (
    0 => 'joplin',
  'maintenance' => false,
  'loglevel' => 0,
  # mail settings
  # password settings
  'datadirectory' => '/var/www/html/data',
  'dbtype' => 'pgsql',
  'version' => '',
  'overwrite.cli.url' => 'http://localhost',
  'overwriteprotocol' => 'https',
  # database settings
  'installed' => true,
  # instance settings
  'theme' => '',

The output of your Apache/nginx/system log in /var/log/____: - - [17/Mar/2022:00:15:10 +0000] "GET /ocs/v2.php/apps/notifications/api/v2/notifications HTTP/1.1" 304 0 "-" "<Browser Info>" "" - - [17/Mar/2022:00:16:14 +0000] "GET /apps/logreader/poll?lastReqId=rbuawsdasdaszi HTTP/1.1" 499 0 "-" "<Browser Info>" ""
2022/03/17 00:16:14 [info] 14#14: *412 epoll_wait() reported that client prematurely closed connection, so upstream connection is closed too while sending request to upstream, client:, server: , request: "GET /apps/logreader/poll?lastReqId=rbuawsdasdaszi HTTP/1.1", upstream: "fastcgi://", host:

Everything else is just normal 200s or the readiness check.

Additional Details

I moved all data and config locations for Nextcloud to an sshfs mount. WAIT! Before you say, that’s the cause, finish reading first.

I moved part of my other server apps to that mount and of course it’s not the fastest in the world, but in all my other server apps the loading time increased from half a second to 1 or 2 or maximum 3 seconds.
This is the experience and trade-off I get on other server apps, when putting all the data onto the mount.

However, with Nextcloud, I had a couple of seconds before, like 5 to 20 seconds maximum and now, after installing the Helm Chart with the newest Nextcloud version, I get at least 20 seconds, up to a minute or even longer wait time for each mouse click. Like, yes, the mount is slower than properly attached storage, but it’s not that much slower. It’s not a 100 times slower.

I wonder what configuration options I still can apply, to better the situation. For example, I disabled the File Access Control plugin, but things are still going slow.

In addition to that, if I change a lot of pages within the Web UI, by using mouse clicks, it can even lead to a 503 error, where the server seems completely gone. I then have to wait 1 or 2 minutes for the server to “come back”…

So, all in all, I expect a couple of seconds delay. Maybe 5 to 10 seconds, I don’t care about that too much. But not 1 minute for each mouse click plus the occasional 503 error. This is too much and unbearable.

Please, before putting all the blame on the sshfs mount and calling it a day, be aware, that the old, previous Nextcloud installation was already very slow compared to other server apps on the same server. Other servers loaded instantly within 100ms to 200ms, while Nextcloud always needed 5 to 20 seconds.

Now, just because of that mount, I cannot wait that much longer, without even understanding the reason. Literally all other server apps I am using are fine and quick enough, but Nextcloud was always sooo slow…

What are your hardware specs?

If you want to try a fun comparison, try spinning up the very minimalist filestash.

Oops, forgot about that.

4 cores @ 2400 MHz

Did you configure Redis?

I did not do any custom configuration, because I partially migrated my old data to the new instance, as that had priority. Now, the slowness did not stop, so I decided to look for help, to get hints from the community.

So, if Redis is not configured by default by the Helm Chart, then I did not configure it. I should look it up, though.

However, as far as I understood, the Helm Chart should be already pretty optimised and to my surprise I did not see any error or relevant warning on the admin page, that usually tells you how to optimise your Nextcloud server.

Redis makes a significant difference in file caching. Definitely set it up. I don’t know the helm chart, but the admin documentation includes some excellent recommendations for improving performance.

Here is a quick docker example… just found on a search. How to make your NextCloud faster with Redis as an in-memory cache using Docker? by Subjectively about this and that

I see.

I looked it up and indeed, it’s turned off by default. I will turn it on and see how it goes. Thanks for the tip. I thought the optimised chart would allow all the bells and whistles for optimisation by default, so I didn’t explicitly check, if it was turned on.

Cool, interested to hear how it goes for you. Also be sure to give filestash a spin on docker for comparison. It is very minimal and very fast.

So, far I successfully enabled Redis.

I also heavily slimmed down the server. I uninstalled all apps, except the absolutely basic ones. I removed external storages and other features. I tried to slimmify as much as reasonable.

Performance improved a bit overall and it’s noticable. However, it’s still very slow. Especially, when I am reloading the page or loading it for the first time, it still takes up to a minute, until it’s finished.

It’s good to see progress, but I wish it wouldn’t always feel like I’m running IntelliJ or whatever huge IDE on the server, eating up so many resources, that it’s very slowed down. (Nextcloud does not even eat all resources, it’s still super slow…)

I also wanted to apply those settings mentioned in that thread, like e.g. increasing pm.max_children. However, it seems like it’s not doable by default through the Helm Chart or even the Nextcloud Docker image. It seems like, this has to be made accessible, manually.


Would you say pm.max_children should help a lot or is it just a minor adjustment?

Take a look at the official server tuning guide.

From my experience PHP memory limit has huge impact - I’m under impression default 512M limit is too low today - my home instance improved after raising PHP memory limit to 1G (or 2G)

While trying to tune the server further, I increased the PHP memory limit to 1024MB, i.e. the environment variable PHP_MEMORY_LIMIT is appropriately set inside the image and container. Not sure, if this actually applies the change, though.

I generally have an issue, detecting, if things work as they should. When looking at the Redis situation again, I started getting doubts, if it is set up correctly. I checked the Memcache guide on the server tuning page and noticed, that I either missed some configuration or it was applied automatically.
It seemed like, it should’ve been applied manually, so I did that.

However, I do not see any difference and now I’m questioning myself, how I am supposed to detect if the tuning is applied successfully. Does the Redis memory caching work? Is everything set up correctly in that regard?
I do not see any relevant log messages at all, hinting at anything.

That said, I used the stopwatch another time and measured the time for complete from scratch loading of the Files page + how long it takes for the file list to fully finish loading, showing the files and folders available.

It took 1 minute and 12 seconds for the Files page to finish loading and another 41 seconds for the file list itself to finish loading, showing all the files and folders, properly.
That means I have to wait about 2 minutes, every single time I enter the main page of Nextcloud. This is absolutely insane.

To improve this, I want to apply the server tuning suggestions, but I’m not sure how to verify and prove, that they are actually applied. I don’t know how I would ask PHP or Nextcloud, if the settings are applied. It all seems convoluted and I don’t trust looking only at the config.php, anymore, as it’s only saying what should be the case, but not necessarily what is the case…

Do you have the richdocuments app installed?

I uninstalled all non-featured apps and some of the featured ones. I only kept the basic ones.

I again looked at the Active Apps page and I don’t see anything which looks like a richdocuments app.

Does it have a different name and is it featured?

Are apps still able to have a performance impact, when installed, but disabled?

No, when disabled they should not have an impact but for a test you could remove that app completely.

I looked at the page with the disabled apps and do not see any richdocuments app.

Are there any other performance impacting apps, besides File Access Control?

The app might be called Nextcloud Office

It’s also ironic how quick and smooth it is to remove apps… No performance issues, at all.
But whenever I have to load a page in Nextcloud, it’s horrible…

I checked and there is no app of the name “Office”, “Nextcloud Office”, “Documents” or anything like that.

Okay, then no idea why it is so slow

Not sure if removing the apps helped or if the cache kicked in just now, but switching to Files again, took 32 seconds to fully load the page and 18 seconds to fully load the file list.

Still, terribly long waiting times, but it has at least significantly improved compared to how it was before.

Actually, loading this page took a very long time. Maybe it’s normal for Nextcloud to be super slow in general…