Optimal number of replicas for Nextcloud server Docker container

For folks using Docker, how many replicas of the Nextcloud server container do you run? Do you have some way to objectively measure performance when you change the number of replicas? Do you have a rule of thumb for how many replicas to use based on user count / usage patterns? Can using more than 1 cause some unexpected things to break?

Intuitively I feel like the answer has to be “as long as nothing breaks, run as many replicas as you can handle with your existing compute, storage, and memory”, but I don’t have a systematic way to approach this. I’m also aware that Apache does its own local work distribution with processes and threads, and that seems like a better “level” at which to spread work across CPUs given I’m hosting Nextcloud on a single bare metal server (so: no opportunity to spread work to other machines). Adding more replicas seems much more of a blunt instrument and I’m not sure it makes sense.

I’m using the image from GitHub - nextcloud/docker: ⛴ Docker image of Nextcloud and I just tried 2 replicas, e.g.:

    image: nextcloud:stable
      replicas: 2

Both app replicas are running on the same bare metal server.

This is a LAN-only self-hosted Nextcloud instance at home with less than 10 intermittent users. I’m probably the heaviest user. I do mostly groupware (calendar, contacts) and also local editing / document syncing throughout the workday. I feel like I’d need something simulating our pattern of multi-user traffic (and to test that with both replicas: 1 and replicas: 2) to get a good performance measurement.

As for multiple replicas potentially breaking things, I’m not sure what saved state exists in the container that would lead to problematic differences between replicas. I use MariaDB as the backend db and redis for caching (in their own separate containers). Everything seems to be working fine so far as I log out, log in, and click around the web UI.

It isn’t obvious if it is faster or slower or the same as with 1 replica. I do see interleaved log messages from nextcloud-app-1 and nextcloud-app-2 containers so Docker (and/or my Traefik reverse proxy?) is doing some amount of load balancing.

I guess while I’m thinking about replicating app I should also consider the number of redis replicas. Anyone scaling out their Nextcloud server’s redis container?

my answer is not based on my Docker and Nextcloud knowledge but more general long professional experience.

high-availability and speed optimization through multiple instances which applies to scaling with Docker as well adds lot of complexity in different areas like setup, upgrade, monitoring, backup, restore, logging… Often it looks good on first glance like login, click around and logout… the problem arise when you run in long term under changing network conditions when existing session on server A for some reason hits server B which has no clue of this session and there is an error or maybe even data loss… and trust me this weird errors are really hard to troubleshoot. if you just look for an advice - as long everything runs on the same hardware - KISS kiss it simple stupid - and stay on one instance for everything. if want to build sch setup to study go on (…and report results :wink: )

1 Like

Aye, KISS is great advice here, and pretty much the opposite of my first idea to run as many replicas as possible! It ain’t broke right now (nobody complains about performance), so yeah, what’s to fix? If this were more of a “homelab” than “homeprod” I’d do more tinkering, but there’s really no need right now.

Nextcloud appears to be built for replication given state (db, cache) are stored elsewhere, but yeah, it is always more complex to add load balancing. I am curious about how far Apache scales up on its own, too. That’s probably configurable.

Despite our conversation, I decided to leave replicas: 2 for now. It’s been running this way for a month so far, apparently without any issues. I want to just keep this going for a while to test it out. Could be handy if I ever scale out this instance.