ownCloud Infinite Scale vs Nextcloud 28 : Comparaison des performances et de l’utilisation de la RAM

ownCloud Infinite Scale et Nextcloud 28 permettent tous deux la synchronisation et le partage de fichiers auto-hébergés, mais ils y parviennent grâce à des architectures serveur très différentes. Cette différence est cruciale pour prévoir la consommation de mémoire, la latence des requêtes, le comportement lors de la mise à l'échelle et l'ampleur des réglages nécessaires au déploiement.

Le principal avertissement doit être pris en compte d'emblée : il n'existe pas de chiffre universel fiable du type « Infinite Scale utilise X Mo tandis que Nextcloud 28 utilise Y Mo ». La consommation de RAM varie en fonction des services activés, du nombre d'utilisateurs simultanés, des tâches en arrière-plan, des systèmes de stockage, du nombre de processus PHP, de la mise en cache, des aperçus, de l'intégration bureautique et des applications. La documentation officielle fournit également des indications différentes concernant la consommation de mémoire pour les deux produits ; par conséquent, considérer ces chiffres comme une référence directe serait trompeur.

Il existe également un problème de cycle de vie. Nextcloud 28, aussi appelé Hub 7, a été lancé en décembre 2023 et son support a pris fin en décembre 2024 ; la dernière version 28.x était la 28.0.14. Depuis octobre 2026, il ne bénéficie plus de correctifs de bogues ni de mises à jour de sécurité régulières. Cette comparaison est donc surtout utile pour comprendre une installation Nextcloud 28 existante ou planifier une migration, et non pour recommander un nouveau déploiement de Nextcloud 28. Consultez le calendrier officiel de maintenance et de publication de Nextcloud .

La différence architecturale est à l'origine de la plupart des compromis en matière de performances.

ownCloud Infinite Scale, souvent abrégé en oCIS dans la configuration et la documentation, est conçu comme un ensemble de services Go. Son environnement d'exécution par défaut permet de démarrer les services intégrés au sein d'un seul processus et de les superviser grâce à un superviseur intégré. Selon ownCloud, cette conception contribue à réduire l'empreinte mémoire, et les services individuels peuvent être déplacés vers d'autres nœuds lorsqu'un déploiement nécessite une montée en charge horizontale. La plateforme ne requiert ni PHP ni base de données applicative traditionnelle pour son fonctionnement de base. Consultez la documentation officielle sur l'architecture d'Infinite Scale et la présentation de l'administration d'Infinite Scale .

Nextcloud 28 suit le modèle classique des applications web PHP. Une architecture de production typique comprend un serveur web tel qu'Apache ou Nginx, des workers PHP ou PHP-FPM, une base de données relationnelle compatible et généralement un système de cache en mémoire. La documentation de Nextcloud recommande APCu pour le cache local et Redis pour le cache distribué et le verrouillage transactionnel des fichiers dans les déploiements en entreprise. Cette architecture confère à Nextcloud une grande flexibilité, mais implique également que la mémoire totale est répartie entre plusieurs processus et services indépendants, au lieu d'être gérée par un seul processus serveur.

Utilisation de la RAM : que signifient réellement les chiffres officiels ?

L'exemple de déploiement en production d'ownCloud recommande explicitement un minimum de 4 à 6 Go de mémoire et précise les besoins supplémentaires en mémoire lorsque l'analyse antivirus est activée. Ce chiffre ne signifie pas qu'« oCIS consomme toujours 4 à 6 Go ». La configuration documentée inclut également les suites bureautiques et autres composants requis. Consultez l' exemple de déploiement en production officiel d'Infinite Scale .

Nextcloud 28 adopte une approche différente dans sa documentation relative aux exigences : il indique que les besoins en RAM varient considérablement selon les utilisateurs, les applications, les fichiers et l’activité, puis recommande un minimum de 128 Mo et une quantité recommandée de 512 Mo par processus . Ceci est particulièrement important avec PHP-FPM, où plusieurs processus de travail peuvent être actifs simultanément. Un serveur configuré pour une forte concurrence peut donc réserver beaucoup plus de mémoire que ne le suggère la valeur par processus. Consultez la configuration système requise pour Nextcloud 28 .

Lequel des deux semblera probablement plus léger en cas de charges de travail axées sur les fichiers ?

Si la charge de travail consiste principalement en l'authentification, la navigation, la synchronisation, le chargement, le téléchargement et le partage, l'environnement d'exécution Go et la conception des services d'Infinite Scale permettent de réduire la surcharge liée à une pile de requêtes PHP. ownCloud utilise également des protocoles binaires tels que gRPC en interne pour certaines communications de ses services. Sur le plan architectural, cela offre à Infinite Scale une solution viable pour une forte concurrence sans multiplier les processus de travail PHP.

Cela ne garantit pas un avantage universel en termes de débit. La latence de stockage peut être prépondérante dans les opérations sur les fichiers, le protocole TLS et les proxys inverses engendrent des frais supplémentaires, le comportement des métadonnées dépend du pilote de stockage choisi et les services optionnels modifient le profil. La documentation de stockage d'ownCloud aborde explicitement l'optimisation de la mémoire et des performances différemment pour le stockage local, NFS et les déploiements basés sur S3. Voir les considérations relatives au stockage à échelle infinie .

Nextcloud 28 offre également d'excellentes performances avec une configuration optimale. Sa documentation indique que la mise en cache en mémoire peut améliorer considérablement les performances du serveur. APCu évite la reconstruction locale répétée des objets PHP fréquemment utilisés, tandis que Redis gère les données du cache distribué et le verrouillage transactionnel des fichiers. Pour un serveur d'entreprise unique, Nextcloud 28 recommande APCu pour le cache local et Redis pour la mise en cache et le verrouillage distribués. Consultez la documentation de Nextcloud 28 sur la mise en cache en mémoire .

Où va la RAM de Nextcloud ?

Pour Nextcloud 28, la « consommation de RAM de Nextcloud » correspond en réalité à la somme de plusieurs budgets. Les processus PHP-FPM consomment de la mémoire en fonction des modules PHP activés et du code applicatif. La base de données nécessite ses propres tampons et sa mémoire de connexion. Redis consomme de la mémoire pour les objets mis en cache et les verrous. APCu conserve un cache local dans chaque environnement PHP. La génération d'aperçus, les intégrations antivirus, Talk, la recherche plein texte et les applications tierces peuvent ajouter leurs propres processus ou activités en arrière-plan.

Ce modèle offre aux administrateurs de nombreux leviers d'optimisation. Réduire le nombre de workers PHP-FPM permet de maintenir un petit serveur opérationnel avec une RAM limitée, mais les requêtes risquent de s'accumuler en cas de forte charge. Augmenter le nombre de workers améliore la concurrence jusqu'à ce que le processeur, la RAM, les connexions à la base de données ou les E/S deviennent le facteur limitant. Utiliser Redis comme cache local peut économiser de la mémoire dans les environnements à faible capacité, mais la documentation de Nextcloud indique qu'APCu est plus rapide pour la mise en cache locale lorsque la RAM disponible est suffisante. Il s'agit d'un véritable compromis entre performances et mémoire, et non d'une configuration unique recommandée pour tous les hôtes.

Où va la RAM d'Infinite Scale ?

Infinite Scale comprend également de nombreux services logiques, mais son environnement d'exécution intégré peut gérer les services intégrés au sein d'un seul processus et exécuter chaque service dans une goroutine. ownCloud décrit cette approche comme une méthode conviviale pour l'administration, permettant de déployer la plateforme tout en conservant la possibilité de séparer les services individuels pour les déploiements distribués. Le superviseur intégré redémarre également les services défaillants et il est spécifiquement démontré qu'il réduit l'empreinte mémoire par rapport à l'exécution de chaque service sous un superviseur externe.

Cette consolidation peut simplifier l'analyse du comportement des ressources sur un seul hôte, mais elle ne fixe pas l'utilisation de la RAM. L'ajout de Collabora ou OnlyOffice, d'analyses antivirus, de services d'identité externes, de composants Redis ou NATS, du traitement des miniatures ou de caches plus volumineux modifie l'empreinte mémoire. Le déplacement des services dans des conteneurs ou des pods Kubernetes distincts peut également augmenter la surcharge de base tout en améliorant l'isolation et la scalabilité horizontale.

Comparaison des performances en fonction de la charge de travail

Comment les évaluer équitablement

Si la performance est le critère déterminant, comparez les performances des deux produits sur le même matériel plutôt que de vous fier à des captures d'écran ou à des mesures de mémoire isolées. Utilisez le même périphérique de stockage, le même chemin réseau, la même méthode de terminaison TLS, le même ensemble de fichiers de test, le même nombre d'utilisateurs et le même comportement client. Chargez les caches avant d'enregistrer les résultats en régime permanent, mais mesurez également le comportement au démarrage à froid.

Les indicateurs utiles comprennent la latence médiane et le 95e percentile pour l'affichage des répertoires, les opérations sur les métadonnées, le chargement et le téléchargement de petits et gros fichiers, ainsi que la création de partages ; le nombre de requêtes effectuées par seconde ; la mémoire résidente totale pour chaque processus concerné ; l'utilisation du processeur ; les IOPS de stockage ; la latence de la base de données Nextcloud ; et l'impact des tâches en arrière-plan. Il est important de mesurer la RAM inactive séparément de la RAM utilisée, car un système qui semble moins gourmand en mémoire au repos peut en allouer beaucoup plus en cas d'utilisation simultanée.

Pour Nextcloud, il faut prendre en compte le serveur web, PHP-FPM, la base de données, Redis et tous les services applicatifs supplémentaires. Pour Infinite Scale, il faut inclure les services oCIS, le proxy inverse, les composants d'identité, l'intégration bureautique, les caches et les services de stockage. Autrement, le résultat se résume à une comparaison d'architectures déguisée en benchmark.

Lequel choisir ?

Optez pour ownCloud Infinite Scale si votre priorité est une plateforme moderne axée sur les fichiers, si vous privilégiez une architecture de services basée sur Go et si vous souhaitez éviter le modèle opérationnel reposant sur des workers PHP et une base de données relationnelle requise pour le serveur principal. Cette solution est particulièrement intéressante pour les organisations qui prévoient une mise à l'échelle horizontale de leurs services ou des environnements de partage de fichiers de grande envergure.

Choisissez une version prise en charge de Nextcloud lorsque l'écosystème d'applications Nextcloud, les intégrations de travail collaboratif, vos connaissances d'administration existantes ou la compatibilité des applications sont plus importants que la réduction du nombre de couches d'exécution. Si vous utilisez actuellement Nextcloud 28, l'optimisation des performances peut encore apporter un bénéfice à court terme, mais le cycle de vie de la sécurité est la raison principale de planifier une mise à niveau, car la version 28 n'est plus prise en charge depuis décembre 2024.

Si la décision porte spécifiquement sur la RAM, les spécifications publiées par les deux fournisseurs ne permettent pas de désigner un vainqueur incontestable. L'architecture d'Infinite Scale exclut PHP et une base de données applicative traditionnelle du cœur du système et est conçue pour une exécution efficace des services, tandis que Nextcloud offre des mécanismes de cache performants et une gestion de la concurrence PHP hautement configurable. Le choix le plus judicieux consiste à comparer l'ensemble des environnements de production que vous prévoyez d'exploiter, avec la même charge de travail et en mesurant la RAM totale du système plutôt que celle d'un processus isolé.