Un cache Nextcloud avec APCu et Redis ne consiste pas à choisir un seul logiciel pour tout faire. APCu conserve rapidement des données sur chaque serveur PHP. Redis peut centraliser les données partagées entre plusieurs nœuds et stocker les verrous transactionnels des fichiers. La bonne configuration dépend donc de l’architecture, pas seulement de la taille de l’instance.
Ce guide s’appuie sur le manuel de Nextcloud 35 et sur le fichier config.sample.php de la branche stable35, consultés le 1er novembre 2026. Il explique le rôle des trois directives de cache, propose une configuration pour un serveur unique, puis précise les changements nécessaires avec plusieurs nœuds. Pour situer ces composants dans l’ensemble de la plateforme, commencez par le guide Nextcloud.
À quoi servent les trois caches de Nextcloud ?
Nextcloud distingue trois usages dans config.php. Ils peuvent employer le même backend, mais ils ne répondent pas au même besoin.
| Directive | Rôle | Choix courant |
|---|---|---|
memcache.local | Accélérer les données propres au serveur web qui traite la requête | APCu |
memcache.distributed | Partager des données de cache à l’échelle de l’instance | Redis partagé |
memcache.locking | Conserver les verrous transactionnels des fichiers | Redis |
memcache.local concerne des valeurs qui peuvent rester différentes d’un serveur à l’autre. APCu est adapté à cet usage car il fonctionne au plus près de PHP. Sur une architecture avec plusieurs nœuds web, chacun possède son propre cache local. Il ne faut donc pas attendre d’APCu qu’il synchronise deux machines.
memcache.distributed concerne des valeurs propres à toute l’installation, par exemple des résultats mis en cache à partir de la base. Le fichier de configuration de Nextcloud indique que cette directive reprend la valeur de memcache.local lorsqu’elle n’est pas définie. Ce comportement reste possible sur un serveur unique, mais il n’est pas adapté à un cluster si le cache local repose sur APCu, car chaque nœud conserverait alors son propre état.
memcache.locking déplace les verrous de fichiers hors de la base de données. Nextcloud recommande Redis pour cet usage afin de réduire la charge SQL et d’éviter les backends susceptibles d’évacuer un verrou de manière imprévisible. Le guide du verrouillage de fichiers Nextcloud détaille le mécanisme et les erreurs à ne pas traiter par une suppression globale du cache.
Nextcloud 35 propose aussi le backend \OC\Memcache\KeyValueCache, qui communique avec Redis ou Valkey sans installer l’extension PHP phpredis. Ce guide se concentre sur le backend classique \OC\Memcache\Redis, car ses prérequis et sa configuration ne doivent pas être mélangés avec ceux de KeyValueCache.
Cache et stockage sont deux sujets différents
Les caches accélèrent des lectures ou conservent des verrous temporaires. Ils ne remplacent ni la base, ni les fichiers, ni une sauvegarde. Une panne Redis peut interrompre des opérations, mais Redis ne devient pas pour autant le stockage principal des documents.
Quelle combinaison choisir selon l’architecture ?
Pour une organisation avec un serveur web unique, le manuel Nextcloud 35 recommande APCu pour memcache.local, puis Redis pour memcache.distributed et memcache.locking. Le coût opérationnel reste limité lorsque Redis fonctionne sur la même machine par socket Unix.
Sans Redis, APCu peut améliorer le cache local, tandis que les verrous restent gérés par la base. La documentation présente cette configuration minimale pour un petit serveur privé. Elle ne traite pas la charge SQL liée au verrouillage et ne constitue pas la recommandation destinée à un serveur d’organisation.
Avec plusieurs serveurs web, chaque nœud utilise APCu localement et tous pointent vers le même service Redis pour memcache.distributed et memcache.locking. Configurer localhost sur chaque machine créerait plusieurs espaces Redis indépendants. Deux nœuds pourraient alors prendre des décisions incompatibles sur une même donnée ou un même verrou.
| Architecture | local | distributed | locking | Point de vigilance |
|---|---|---|---|---|
| Un serveur, sans Redis | APCu | Valeur locale par défaut | Base de données | Charge SQL du verrouillage |
| Un serveur avec Redis | APCu | Redis, selon le besoin | Redis | Permissions de la socket ou du port |
| Plusieurs nœuds web | APCu sur chaque nœud | Redis partagé | Redis partagé | Même backend et même configuration partout |
| Cluster Redis ou Sentinel | APCu sur chaque nœud | Backend partagé pris en charge | Backend partagé pris en charge | Bascule testée pendant des écritures |
Le nombre d’utilisateurs ne suffit pas à choisir. Une petite équipe peut générer beaucoup de verrous avec la synchronisation, WebDAV ou l’édition collaborative. À l’inverse, une instance d’archive peu modifiée peut produire moins de concurrence. Appuyez la décision sur les opérations réelles, la charge de la base et le besoin de bascule.
Comment configurer APCu et Redis sur un serveur unique ?
Avant de modifier Nextcloud, vérifiez que l’extension APCu est chargée par le PHP utilisé par le serveur web et que l’extension Redis est disponible lorsque vous utilisez le backend \OC\Memcache\Redis. Une commande lancée avec PHP CLI ne prouve pas que PHP-FPM ou le module Apache charge les mêmes extensions. Comparez donc la configuration du terminal avec l’écran d’administration de l’instance.
Sauvegardez config/config.php, vérifiez sa syntaxe et adaptez les chemins à l’installation. Pour Redis installé sur la même machine, le manuel Nextcloud recommande une socket Unix. Voici une base de configuration :
'memcache.local' => '\\OC\\Memcache\\APCu',
'memcache.distributed' => '\\OC\\Memcache\\Redis',
'memcache.locking' => '\\OC\\Memcache\\Redis',
'redis' => [
'host' => '/run/redis/redis-server.sock',
'port' => 0,
'timeout' => 0.0,
'read_timeout' => 0.0,
],
Le chemin de la socket n’est pas universel. Selon la distribution ou le conteneur, il peut se trouver ailleurs ou ne pas être créé. Redis doit autoriser l’utilisateur du serveur web à ouvrir cette socket. Le réglage unixsocketperm et le groupe système doivent donc être cohérents avec le compte qui exécute PHP. Une permission trop large expose inutilement le service, tandis qu’une permission trop restrictive produit une erreur de connexion au démarrage de Nextcloud.
Si Redis écoute sur TCP, limitez-le à un réseau privé ou à l’hôte attendu. Le fichier d’exemple de Nextcloud 35 accepte notamment host, port, timeout, read_timeout, user, password, dbindex et un contexte TLS. N’exposez pas le port Redis sur Internet. Utilisez une authentification et, lorsque le trafic traverse un réseau qui n’est pas entièrement maîtrisé, chiffrez la connexion.
Ne copiez pas les secrets dans un dépôt
Le nom d’utilisateur Redis, le mot de passe et les certificats dépendent du déploiement. Conservez-les dans le mécanisme de secrets prévu par votre infrastructure. Vérifiez aussi que PHP web et PHP CLI reçoivent les mêmes valeurs si les tâches occ et cron.php doivent accéder à Redis.
Que faut-il changer avec plusieurs nœuds Nextcloud ?
La configuration de cache devient une dépendance de l’architecture. Tous les nœuds web doivent charger les mêmes classes de cache, utiliser les mêmes paramètres Redis et accéder au même espace logique. Une différence de mot de passe, de base Redis, de préfixe ou de route réseau peut créer une panne partielle difficile à reproduire.
Le préfixe memcache_customprefix permet d’éviter des collisions lorsque plusieurs installations utilisent le même service de cache. Nextcloud 35 indique aussi qu’il peut participer à une restriction par ACL. Ne partagez pas un compte Redis trop permissif entre toutes les applications de l’entreprise. Un utilisateur dédié et un préfixe propre limitent le périmètre d’une erreur de configuration.
Pour la haute disponibilité, Nextcloud 35 documente un serveur unique, un ensemble répliqué piloté par Sentinel et un cluster. Le choix ne se résume pas au nombre de réplicas. Il faut vérifier la cohérence des lectures pendant la bascule, car une lecture de verrou sur un réplica en retard peut provoquer une erreur de fichier verrouillé. Le fichier config.sample.php déconseille notamment le mode qui distribue aléatoirement les lectures d’un cluster Redis lorsqu’il sert au verrouillage.
Ne transformez pas Redis en point de panne silencieux. Surveillez sa disponibilité, sa mémoire, ses refus de connexion et les délais observés depuis chaque nœud. Testez ensuite une vraie bascule pendant un envoi et un renommage de fichier. Le guide de haute disponibilité Nextcloud replace Redis dans la chaîne complète avec le répartiteur, la base, le stockage et les tâches de fond.
Comment vérifier la configuration sans se fier à une page verte ?
Commencez par lire la configuration réellement chargée. Adaptez le compte système et le chemin de occ à votre installation :
sudo -u www-data php occ config:system:get memcache.local
sudo -u www-data php occ config:system:get memcache.distributed
sudo -u www-data php occ config:system:get memcache.locking
sudo -u www-data php occ config:system:get redis host
sudo -u www-data php occ status -e
Une sortie correcte confirme les valeurs, mais pas le comportement sous charge. Vérifiez aussi que Redis répond depuis le même compte et le même réseau que PHP. Pour une socket locale, un test peut prendre cette forme :
sudo -u www-data redis-cli -s /run/redis/redis-server.sock PING
La réponse attendue est PONG. Si redis-cli n’est pas installé sur le serveur web, utilisez un contrôle équivalent depuis l’environnement applicatif sans ajouter un paquet uniquement pour satisfaire un test ponctuel.
Exécutez ensuite une recette fonctionnelle :
- ouvrir l’aperçu d’administration et relever les avertissements liés au cache ;
- téléverser un petit fichier depuis le navigateur ;
- le renommer puis le déplacer ;
- synchroniser le même dossier avec un client de bureau ;
- effectuer deux modifications concurrentes sur une copie de test ;
- contrôler
nextcloud.logautour de l’heure exacte ; - répéter depuis chaque nœud web si l’instance est distribuée.
Recherchez les erreurs RedisException, les refus de permission sur la socket, les délais de connexion et les exceptions de cache. Un PONG ne valide pas l’extension PHP, les droits de la socket, la classe déclarée dans config.php ni la cohérence entre plusieurs nœuds.
Pour suivre les délais et la disponibilité dans le temps, le guide Superviser Nextcloud avec Prometheus explique comment séparer les métriques applicatives, système et HTTP. Redis demande ses propres métriques, car l’endpoint Nextcloud ne remplace pas la supervision du service de cache.
Quelles erreurs de configuration reviennent le plus souvent ?
La première erreur consiste à employer APCu comme cache partagé dans un cluster. APCu reste local. Il peut être excellent pour memcache.local, mais il ne synchronise pas les données de plusieurs serveurs.
La deuxième est de définir Redis dans config.php sans installer ou charger l’extension PHP correspondante. Nextcloud ne peut pas instancier la classe demandée et l’instance peut devenir inaccessible. Vérifiez les modules avant d’enregistrer la configuration, puis gardez une copie restaurable du fichier.
La troisième est de viser une socket qui existe mais que PHP ne peut pas ouvrir. Le compte de Redis, le groupe de la socket, le compte du serveur web et les permissions doivent être lus ensemble. Ne résolvez pas ce problème avec un mode accessible à tous.
La quatrième est d’exposer Redis sur une interface publique, sans ACL ni chiffrement. Le service doit rester sur une boucle locale, une socket Unix ou un réseau privé filtré. Si un accès distant est nécessaire, réduisez les sources autorisées et protégez l’authentification.
La cinquième est de valider seulement l’ouverture de la page d’accueil. Les erreurs de cache peuvent apparaître pendant un verrou, une tâche de fond, une synchronisation ou une bascule. La recette doit couvrir des écritures, le CLI, cron.php et tous les nœuds applicatifs.
Conclusion
Pour un serveur Nextcloud d’organisation, APCu répond au cache local et Redis au cache distribué ainsi qu’au verrouillage. Pour plusieurs nœuds, APCu reste local à chaque serveur tandis que le cache distribué et les verrous doivent pointer vers un backend partagé cohérent.
La configuration fiable tient en quatre contrôles : modules PHP réellement chargés, socket ou réseau Redis correctement protégés, valeurs identiques sur tous les nœuds et recette d’écriture après changement. Sauvegardez config.php, préparez le retour arrière et surveillez Redis comme un composant de production.