Nextcloud seems to have a bad reputation around here regarding performance. It never really bothered me, but when a comment on a post here yesterday talked about huge speed gains to be had with Postgres, I got curious and spent a few hours researching and tweaking my setup.
I thought I’d write up what I learned and maybe others can jump in with their insights to make this a good general overview.
To note, my installation initially started out with this docker compose stack from the official nextcloud docker images (as opposed to the AIO image or a source installation.) I run this behind an NGINX reverse proxy.
Sources of information
Server tuning on Nextcloud Docs: Most of this are very basic things that are already taken care of in the docker image or in the proxy companion image I’m using. The one thing I haven’t tried and that comes up in other places, too, is using Imaginary for image preview generation.
Eking out some Nextcloud Performance mainly talks about using a socket connection for redis, but also mentions logging to syslog (have not found a good source of information for this), using postgres, using imaginary for image previews
Improvements
Migrate DB to Postgres
What I did first is migrate from maridb to postgres, roughly following the blog post I linked above. I didn’t do any benchmarking, but page loads felt a little faster after that (but a far cry from the “way way faster” claims I’d read.)
Here's my process
add postgres container to compose file like so. I named mine “postgres”, added a “postgres” volume, and added it to depends_on for app and cron
run migration command from nextcloud app container like any other occ command. The migration process stopped with an error for a deactivated app so I completely removed it, dropped the postgres tables and started migration again and it went through. after migration, check admin settings/system to make sure Nextcloud is now using postgres. ./occ db:convert-type --password $POSTGRES_PASSWORD --all-apps pgsql $POSTGRES_USER postgres $POSTGRES_DB
remove old “db” container and volume and all references to it from compose file and run docker compose up -d --remove-orphans
Redis over Sockets
I followed above guide for connecting to Redis with sockets with details as stated below. This improved performance quite significantly. Very fast loads for files, calendar, etc. I haven’t yet changed the postgres connection over to sockets since the article spoke about minor improvements, but I might try this next.
Hints
the redis configuration (host, port, password, …) need to be set in config/config.php, as well as config/redis.config.php
the cron container needs to receive the same /etc/localtime and /etc/timezone volumes the app container did, as well as the volumes_from: tmp
EDIT Postgres over Sockets
I’m now connecting to Postgres over sockets as well, which gave another pretty significant speed bump. When looking at developer tools in Firefox, the dashboard now finishes loading in half the time it did before the change; just over 6s. I followed the same blog article I did for Redis.
Steps
in the compose file, for the db container: add volumes /etc/localtime and /etc/timezone; add user: "70:33"; add command: postgres -c unix_socket_directories='/var/run/postgresql/,/tmp/docker/'; add tmp container to volumes_from and depends_on
in nextcloud config.php, replace 'dbhost' => 'postgres', with 'dbhost' => '/tmp/docker/',
Outlook
What have you done to improve your instance’s performance? Do you know good articles to share? I’m happy to edit this post to include any insights and make this a good source of information regarding Nextcloud performance.
I’ve been a proponent here for a few months on using postgres/redis every time someone shits on NC for performance. While I agree the database change itself isn’t a huge improvement, it pays for itself long term in larger volume installs when you and your organization/group get using it heavily. The redis connected on socket like the AIO mastercontainer sets up is where the real juice comes from, but only on an install that gets used so it caches properly. The first time you fire it up, it’s pretty slow but as it gets used, things are much better.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
I’ve been a proponent here for a few months on using postgres/redis every time someone shits on NC for performance. While I agree the database change itself isn’t a huge improvement, it pays for itself long term in larger volume installs when you and your organization/group get using it heavily. The redis connected on socket like the AIO mastercontainer sets up is where the real juice comes from, but only on an install that gets used so it caches properly. The first time you fire it up, it’s pretty slow but as it gets used, things are much better.