Problématique
Contrairement à d’autres outils de gestion de données qui ne chargent que les données présentées à l’écran ou des données filtrées, et n’appliquent les calculs que sur les données chargées, dans Grist toutes les données sont chargées à chaque ouverture du document (dans le moteur de données et dans le navigateur), et tous les calculs sont exécutés en même temps.
En effet, Grist a été conçu pour gérer des ensembles de données comparables à la taille d’une feuille de calcul, soit des volumes inférieurs à 100 000 lignes. Dans ce contexte, le chargement complet des données est efficace et plus simple à mettre en œuvre. Cependant, il a pour conséquence la détérioration des performances sur les documents volumineux : temps de chargement rallongés, indication « Still working » qui n’aboutit pas, écran vide. Plusieurs facteurs d’un document sont en jeu :
- le nombre de lignes
- le nombre de formules
- la taille des données
- la taille des PJ
NB : l’équipe de Grist travaille activement à la meilleure prise en compte des données volumineuses. C’est un gros projet répertorié ici : Support larger databases · Issue #43 · gristlabs/grist-core · GitHub
Le format des documents (SQLite) restera le même, mais la bibliothèque qui manipule les documents sera plus performante, permettant ainsi des applications plus gourmandes. Cependant, le code source est pour l’instant propriétaire (GitHub - gristlabs/megagrist: Shiny and awesome data engine for Grist) et cette fonctionnalité sera potentiellement réservée à la version « Grist Entreprise ».
Sources :
Limites recommandées
- Taille du document : 1Go max (PJ + données)
- Nombre de lignes : plusieurs centaines de milliers.
Source : Limites des données dans Grist
Limits - Grist Help Center
- Les documents dépassant 20MB peuvent ralentir ou rencontrer des limites de mémoire en fonction de leur complexité. Par exemple, un document avec 100 000 lignes et 24 colonnes numériques atteindrait cette limite recommandée.
Source : Limits - Grist Help Center
NB : sur les documents qui dépassent les limites recommandées, il faudra s’attendre à des lenteurs lors du premier chargement du document mais aussi lors de la configuration des permissions avancées - en effet, à chaque bascule sur un autre utilisateur (via la fonctionnalité « Voir en tant que »), toutes les données sont à nouveau chargées.
Améliorer les performances
Utiliser les formules d’intialisation
C’est probablement l’action la plus impactante sur les performances d’un document (avec le fait de réduire le nombre de lignes).
Transformer les formules en formules d’initialisation !
Les formules d’initialisation peuvent se déclencher lors de la création d’une nouvelle ligne, et être exécutées à nouveau sur modification d’autres colonnes que l’on peut spécifier. Cela évite le re-calcul des données à chaque ouverture du document, et c’est donc extrêmement utile pour éviter des calculs coûteux.
Quasi toutes les formules peuvent être transformées en formules d’initialisation, exceptées celles qui utilisent des données d’autres tables (avec un lookup par exemple) - car il n’est pas possible de redéclencher sur modification de champs d’une autre table.
Réduire la taille du document
« Faire le ménage » régulièrement
C’est un peu comme garder son bureau propre, c’est important 
Il faut penser à supprimer les tables ou les colonnes non utilisées, notamment en allant voir dans les « Données source ». Vérifier aussi qu’il n’y ait pas de tables en doublons, ou de tables générées automatiquement, du type « Grist_hidden_import ».
Externaliser les PJ
Les données + pièces jointes dans un seul document sont limitées à 1 Go.
En attendant la possibilité d’externaliser les PJ (Externalized attachments · Issue #1021 · gristlabs/grist-core · GitHub), il est recommandé de stocker l’image sur un service de stockage externe. Il est possible d’inclure l’URL de l’image dans une colonne et la prévisualiser facilement à l’aide du widget personnalisé « Image Viewer ».
Supprimer une partie de l’historique
Il y a 2 « types » d’historiques dans Grist :
- l’historique des actions d’un document (les N dernières actions réalisées sur un document)
- l’historique des versions d’un document (les « instantanés » ou snapshots en anglais)
Ces données peuvent être lourdes. Pour les instances françaises gérées par l’ANCT et la DINUM, une limite d’historique de 10Mo a été établie par défaut. Passée cette limite (avec une petite marge qu’autorise Grist), Grist supprime l’historique plus ancien. L’action décrite ci-dessous ne devrait donc être utile aux utilisateurs de ces instances que pour supprimer définitivement les pièces jointes non utilisées.
Sinon, pour supprimer une partie de l’historique des actions, aller dans Paramètres > Console API
Dans la section docs, exécutez cette requête
POST /docs/{docId}/states/remove
En passant ce corps de requête (request body) :
{
"keep": 1000
}
Nettoyer les PJ non utilisées
- Supprimer les PJ des tables
- Recharger le moteur de données si nécessaire
- Lancer la requête suivante pour supprimer les PJ non utilisées :
curl -H 'Content-Type: application/json' -H "Authorization: Bearer $BEARER" -X POST -d '{}' https://$DOMAIN/api/api/docs/$DOC_ID/attachments/removeUnused
Sachant que $BEARER, $DOMAIN et $DOC_ID sont des variables à définir avant la requête.
Les PJ non utilisées sont scannées et nettoyées périodiquement - toutes les heures environ. Cependant, si vous préférez lancer un nettoyage immédiat, c’est possible via la requête de nettoyage de l’historique (cf point précédent), qui permet également de lancer la tâche de suppression de l’espace non occupé dans le document Grist (vacuum).
Source : Delete attachment from trigger formula - #2 by dmitry-grist - Ask for Help - Grist Creators
Enlever le widget Bloc-notes
Le widget personnalisé « Bloc-notes » stocke l’intégralité du document du Bloc-notes dans la cellule, ce qui inclut les images (il les encode sous forme de texte à l’intérieur d’une cellule). Ainsi, plusieurs images dans le Bloc-notes peuvent faire exploser la taille du document.
Optimiser les formules
Utiliser le chronomètre pour repérer les calculs lents
Dans Paramètres > Chronomère de formule, lancer le début du chrono et faire des actions qui impliquent le calcul de formules (ajout d’une ligne par exemple).
Retourner dans les paramètres, arrêter le chronomètre et observer la table des résultats. Trier la colonne « Durée totale » de Z à A, afin que les formules qui prennent le plus de temps apparaissent en premier. Examiner et essayer d’optimiser toute formule dont le calcul prend plus d’1 seconde.
Supprimer des colonnes cachées problématiques
Des colonnes d’aide sont créées en arrière-plan pour différents types de colonnes afin de permettre le stockage des informations supplémentaires nécessaires. Il est possible que le chronométrage des formules (étape précédente) révèle des colonnes d’aide lentes. On les reconnait facilement dans le tableau des résultats du chronomètre car elles sont précédées d’un #.
- Trouver les colonnes d’aide via l’API :
La console API est à disposition pour faciliter la tâche. Elle se situe dans les Paramètres > « Console de l’API ».
La requête à utiliser pour trouver les colonnes cachées est la suivante :
https://$host/api/docs/$docid/tables/$tableid/columns?hidden=true
- Suppression d’une colonne d’aide via l’API :
Appliquer cette modification par colonne d’aide :
curl -XDELETE -H "Authorization: Bearer $key" -H "Content-Type: application/json" https://$host/api/docs/$docid/tables/$tableid/columns/$columnid
Source: Grist accepting data very slowly - #4 by anais-grist - Grist Creators
Résoudre les erreurs
- Certaines formules pointent vers des colonnes qui n’existent plus
- Corriger les erreurs de type
Invalid Ref.dans les colonnes contenant des références. Pour les trouver facilement, appliquer un filtre sur la colonne, elles s’afficheront en premier. - Corriger les erreurs dans les formules de formatage conditionnel
Éviter l’utilisation de .all
- Éviter l’utilisation de la fonction
.allautant que possible, car elle cherche tous les enregistrements de la table. Préférer un.lookupRecords()avec un filtre. Par exemple pour la conditionandsur des colonnes différentes, utiliser :
for r in Items.lookupRecords(Asset=rec.Asset) if (rec.List in r.List.Overlapping)
plutôt que :
for r in Items.all if(r.Asset == rec.Asset and rec.List in r.List.Overlapping)
Source: Performance Optimisation - #2 by paul-grist - Ask for Help - Grist Creators
On peut également utiliser les intersections pour des conditions « ou » :
Par exemple, pour trouver les enregistrements pour lesquels le Nom est égal à « A » ou le Nom est égal à « B » :
records = set(Table.lookupRecords(Nom="A")) | set(Table.lookupRecords(Nom="B"))
Sachant que l’opérateur | représente l’union de deux ensembles et la fonction « set » permet de garder uniquement les valeurs uniques.
NB : Par contre il n’y a pas le choix d’utiliser le .all pour des comparaisons
sum(r.Quantite for r in Table.all if(4 < r.Prix < 10))
Désactiver la mise à jour automatique des données selon certaines conditions
Si l’on souhaite que les calculs soient automatiques sur certaines données mais pas sur d’autres, c’est à dire « mettre en pause » la formule pour certaines données (par exemple ne pas mettre à jour les moyennes datant de plus d’un trimestre, mais mettre à jour les autres), il est possible de créer une colonne « Pause » (booléen true ou false) et utiliser la fonction PEEK, qui va retourner la valeur précédente de l’enregistrement.
Par exemple, si on a une table avec une colonne A qui contient du texte, une colonne B qui contient une formule pour afficher le texte de A en majuscules (UPPER($A)), on utilisera :
if $Pause:
return PEEK($B)
UPPER($A)
Cette formule signifie : si la colonne $Pause contient la valeur « true » pour cet enregistrement, retourner la valeur précédemment enregistrée dans la table. Sinon, appliquer la fonction.
Source : www.community.getgrist.com/t/optimizing-summary-tables-and-lookups/5221/11?u=aude
Séparer les données anciennes
Détacher les tables groupées
Il est possible de « détacher » la table groupée de la table source, pour convertir les formules en données. L’inconvénient est que la table groupée ne sera plus mise à jour.
Créer plusieurs documents
Diviser la donnée dans plusieurs documents, pour diluer la charge. Par exemple, créer une copie « historique » du document, avec les années précédentes.
Avoir une bonne connexion internet
Nous avons recueilli de nombreux retours utilisateurs sur des performances altérées qui étaient en fait dues à des connexions instables ou mauvaises. Cela peut provoquer des erreurs du type « Network error when attempting to fetch resource » ou l’indication « Still Working » avec une erreur « Connection is lost - Attempting to reconnect ». Plus les documents sont volumineux, plus il sera important d’avoir une bonne connexion pour permettre un chargement rapide des données.
Forte volumétrie : un exemple de performances
Sur l’un de nos documents qui dépasse les limites recommandées - 140k lignes, un total de données de 50MB (pas de PJ), avec l’avantage de ne contenir que des formules d’initialisation - le temps de premier chargement du document est long (environ 30sec / 1min) et les temps de chargement lors de la configuration des permissions avancées également. Par contre, l’ajout de nouvelles lignes et l’ouverture des différentes pages reste très rapide, quasi-instantanée.
la recommendation devient donc : externalisez les pièces jointes 