Aller au contenu
Contact us

Performances et charge sur le serveur Nextcloud

L'application contient le plan et l'historique d'une migration ; elle ne déplace elle-même aucun fichier. La lecture des sources, la migration des fichiers et de leurs versions ainsi que la rédaction des rapports sont assurées par le serveur SMART Migration, sur une machine Windows de votre réseau, qui écrit dans Nextcloud Files comme n'importe quel autre client. Pour l'application, le serveur Nextcloud stocke les définitions des tâches et les résultats, et répond aux appels du serveur SMART Migration et des personnes qui utilisent l'application.

Uniquement des appels courts

Chaque appel de SMART Migration reçoit une réponse immédiate. Aucune requête n'est maintenue ouverte sur le serveur Nextcloud pendant que SMART Migration attend du travail.

Une interrogation par application ouverte

Une application ouverte ne demande qu'une chose à la fois à Nextcloud : toutes les 5 secondes pendant qu'une tâche s'exécute, toutes les 30 secondes lorsque rien ne s'exécute, et pas du tout lorsque son onglet de navigateur est masqué.

Pagination sur le serveur

Chaque liste est filtrée, triée et paginée sur le serveur, chaque chiffre du Tableau de bord est calculé par la base de données, et une arborescence n'est construite que dans la mesure où elle est dépliée.

C'est SMART Migration qui contacte l'application ; l'application ne l'appelle jamais. Ses appels sont peu nombreux, courts et reçoivent une réponse immédiate.

AppelFréquence
Demande de la tâche suivanteEnviron toutes les 10 secondes tant qu'il dispose d'un emplacement libre et qu'aucune tâche n'est en attente, puis immédiatement de nouveau après s'en être vu attribuer une. Une tâche passée à l'état Prêt démarre donc en 10 secondes environ.
Le signal de présenceToutes les 30 à 60 secondes, afin que l'indicateur En direct sache que le serveur fonctionne.
Progression, résultats et journal de sessionPendant l'exécution d'une tâche ; le journal de session par lots de 1 000 messages au maximum.
Problèmes de fichiersPar lots de 1 000 au maximum par appel.

La limitation de débit propre à Nextcloud répond trop de requêtes au-delà de 120 requêtes par minute pour une tâche depuis un même compte ; ainsi, même un client qui interroge sans interruption ne peut pas surcharger le serveur.

Une application ouverte interroge son propre Nextcloud par une seule petite requête, et l'indicateur En direct, les tableaux, les notifications d'exécution et le Tableau de bord suivent tous ses réponses. Lorsqu'une tâche s'exécute ou est sur le point de démarrer, elle interroge toutes les 5 secondes ; lorsque rien ne s'exécute, toutes les 30 secondes ; lorsque l'onglet du navigateur est masqué, pas du tout. Un tableau n'est relu que si ce qu'il affiche a changé : lorsque SMART Migration se signale sans rien modifier, cela ne coûte rien aux tableaux ouverts. Actualiser, en haut à droite, relit immédiatement l'onglet ouvert, par une requête identique à celle du tableau.

Les chiffres de migration du Tableau de bord sont calculés par la base de données et conservés jusqu'au début ou à la fin d'une exécution : les problèmes de fichiers enregistrés pendant l'exécution des tâches n'entraînent pas un nouveau calcul.

Volumes pour lesquels l'application est conçue et mesurée

Section intitulée « Volumes pour lesquels l'application est conçue et mesurée »

L'application est dimensionnée et mesurée pour 100 groupes, 50 étiquettes, 25 000 tâches, 75 000 lignes de l'Historique d'exécution, 200 000 problèmes de fichiers et quatre tâches exécutées simultanément, sur un petit serveur doté de 2 cœurs de processeur et d'un memory_limit PHP de 512 Mo. À ces volumes, la liste d'un onglet répond en une seconde environ ou moins, et l'interrogation d'une application ouverte en une fraction de seconde.

Chaque requête de l'application occupe sa mémoire PHP un bref instant et la libère dès qu'elle a reçu sa réponse. Mesures effectuées aux volumes ci-dessus, part propre à Nextcloud d'environ 40 Mo incluse :

RequêteMémoire PHP
L'interrogation d'une application ouverte, et le Tableau de bordEnviron 45 Mo
Historique d'exécution : l'arborescence, la liste, les filtres et Tout développer45 à 75 Mo
Historique d'exécution : la carte de synthèse d'un groupeEnviron 45 Mo
Problèmes de fichiers85 à 95 Mo
TâchesEnviron 140 Mo

Nextcloud consigne un avertissement dans son journal pour chaque requête qui utilise plus de la moitié de memory_limit — 256 Mo pour 512 Mo —, si bien que chaque requête de l'application en reste largement éloignée.

L'Historique d'exécution est la seule liste qui ne fait que croître : ses exécutions sont conservées jusqu'à ce que quelqu'un les supprime ou que le Retention schedule d'une tâche le fasse, et chaque tâche récurrente en ajoute. Ses vues ne conservent donc jamais toutes les exécutions en mémoire. Elles les lisent par tranches, ne gardent que quelques valeurs par exécution, et ne lisent en entier que les exécutions affichées à l'écran et les groupes dépliés. Une vue de 75 000 exécutions nécessite 45 à 75 Mo de mémoire PHP, et une vue de 225 000 exécutions 50 à 115 Mo : chaque exécution supplémentaire ajoute au plus quelques centaines d'octets. La carte de synthèse d'un groupe ne lit que les exécutions de ce groupe.

Dimensionnez PHP pour les utilisateurs, pas pour l'application

L'application n'a besoin d'aucun worker PHP dédié : les appels de SMART Migration sont courts, et aucun n'est maintenu ouvert. Dimensionnez PHP-FPM pour les personnes qui utilisent Nextcloud, conformément aux recommandations d'optimisation de Nextcloud. La requête la plus lourde, l'onglet Tâches avec 25 000 tâches, nécessite environ 140 Mo de mémoire PHP un bref instant ; conservez donc memory_limit à 512 Mo, comme le recommande Nextcloud.

Deux tâches d'arrière-plan s'exécutent dans le cron propre à Nextcloud, et aucune n'effectue d'appel sortant :

  • Toutes les 5 minutes, les mots de passe d'application créés pour les utilisateurs de destination sont révoqués une fois leurs exécutions terminées — à partir d'une table de quelques lignes.
  • Toutes les heures, les calendriers de conservation des tâches sont appliqués : les exécutions qui dépassent le Retention schedule de leur tâche sont supprimées, pour les tâches qui en ont un.

L'application fonctionne sur les bases de données prises en charge par Nextcloud — MariaDB et MySQL, PostgreSQL et SQLite — et est installée et vérifiée automatiquement sur chacune d'elles à chaque modification de l'application. Ses tables disposent des index que lisent ses listes et ses interrogations.

Voir aussi