Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud Performance Tuning.

If you’ve ever noticed Nextcloud feeling sluggish when a lot of people are using it at once, or when you’re dealing with large files, this episode is for you. At NZRT, performance tuning comes down to three main areas: caching, PHP configuration, and database optimisation. Let’s walk through each one.

First up is caching, and the tool NZRT uses here is Redis. Redis is an in-memory data store, and Nextcloud integrates with it really well. The configuration lives in Nextcloud’s main config file, and what it does is tell Nextcloud to use Redis for three things. Local memory caching, which is the everyday object cache that reduces how often Nextcloud has to hit the database. Distributed locking, which prevents conflicts when multiple users access or modify the same files at the same time. And session storage, which is what makes logins feel fast. You point Nextcloud at Redis running on localhost, on port 6379, and give it a password. That’s the core setup. The payoff is fewer database queries, faster page loads, and much smoother performance for things like Nextcloud Talk and the Calendar app, which are especially chatty with the cache.

Next is PHP-FPM tuning, and this one is about making sure PHP can handle many users at once without running out of workers. The configuration file for Nextcloud’s PHP pool sets a dynamic process model, meaning the number of running PHP processes scales up and down with demand. The key numbers here are: a maximum of 100 child processes so you can handle heavy load, 20 processes started at boot so you’re ready to go immediately, a minimum of 10 spare servers sitting idle waiting for requests, and a maximum of 50 spare servers at any given time. Each worker also resets itself after 500 requests, which keeps memory usage healthy over time. On top of that, the PHP settings themselves are tuned for large files. Upload limits and the maximum post size are both set to 2 gigabytes, and the memory limit per PHP process is set to 512 megabytes. If you’re handling Dolibarr invoice exports or large WordPress media uploads through Nextcloud, these limits matter.

Now let’s talk about database optimisation. NZRT runs MySQL, and there are a couple of things you can do here. First, you can enable query caching through Nextcloud’s own command-line tool, which tells Nextcloud to cache the results of repeated database queries rather than running them every time. Second, you can run an optimise command directly against the file cache table in MySQL. This table can grow quite large over time and optimising it reclaims space and improves read performance. Third, you can use Nextcloud’s system info command to pull diagnostic output and check database health at a glance.

For file input and output, the recommendation is to use an SSD for your primary Nextcloud data directory, because fast random write performance makes a noticeable difference when many users are uploading files. If you’re mounting network storage, like a NAS, you want to use asynchronous writes and tune your SMB mount options. The mount command you’d use includes flags like async to avoid blocking on writes, hard and intr so the system handles network interruptions gracefully, and you can specify the protocol version to match your NAS setup. NZRT uses this approach for archival storage mounted from a local network path.

Finally, monitoring. You want to keep an eye on three things. Redis cache hit rate, which you can check using the Redis command-line tool’s stats output. This tells you how often Redis is actually serving data versus falling through to the database. PHP-FPM pool status, where a simple process list filtered to your Nextcloud pool shows you how many workers are active. And slow query logging in MySQL, where you can turn on a slow query log and set a threshold of two seconds, so any database query taking longer than that gets flagged for review.

To put this all in context, NZRT’s Nextcloud instance supports over 50 concurrent users who regularly work with large files. Redis caching is considered essential, particularly because Talk and Calendar generate a lot of short, repeated calls that would otherwise hammer the database. Getting these settings right means the system stays responsive even during busy periods.

If you want to go deeper, the related wiki notes on Administration Overview, Architecture and Tech Stack, and Logging and Monitoring are good next stops.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.