L'objectif de cet article est de proposer des solutions et des outils en vue d'analyser et améliorer les performances d’une application Voozanoo4.
Les quick wins
Cette section liste plusieurs actions permettant d’améliorer les performances d’une application Voozanoo4.
Limiter le nombre d’informations dans les formulaires
Dès qu’un formulaire devient trop long (trops de champs, trop d’opérations, etc.), il est nécessaire de le diviser en plusieurs pages.
Si l’on suit cette logique, l’utilisation du WidgetPages (les onglets) est à proscrire.
Passer les dataqueries en “lecture seule”
Passer les dataqueries qui n’ont pas besoin d’être en “lecture/écriture” (mode="rw") en “lecture seule” (mode="r") permet de désactiver les contrôles de cohérences, très gourmands en performances.
Désactiver les contrôles de cohérences sur les formulaires qui n’en n’ont pas besoin
Pour les formulaires où il n’est pas possible de passer tous les dataqueries en “lecture seule” mais où les tests de cohérences ne sont pas souhaités, il est possible de désactiver ces derniers en ajoutant un noeud <coherence_test>false</coherence_test> à la balise <config> du formulaire (utiliser la propriété “form.config” dans epicraft).
Si la démarche est pertinente pour le projet, il est également possible des droits sur les tests de cohérence. Pour en savoir plus, se référer à l’article Appliquer les droits sur les tests de cohérence.
Appliquer les droits sur les contrôles de cohérence
L’article Appliquer les droits sur les contrôles de cohérence explique comment activer et créer des contrôles de cohérences propres à certains groupes d’utilisateurs. Ce paramétrage peut, potentiellement, améliorer les performances de l’application.
Améliorer les requêtes sur les groupes
S’il y a des requêtes sur la table {pj}_pj_group dans le but de manipuler les groupes d’un projet, ajouter une condition WHERE id_axis IS NOT NULL pour éviter de récupérer les groupes-utilisateurs inutilement.
Consulter les requêtes XHR du formulaire présentant des lenteurs
Vérifier dans la console du navigateur si les requêtes XHR effectuées par le formulaire sont cohérentes (pas de répétition d’une même requête, pas de requête inutile, etc.) et si certaines sont particulièrement longues.
Consulter le plan de test du projet
Ce plan de test remonte les problèmes repérés au sein du projet, notamment les problèmes d’index.
Il est disponible via l’interface “Paramètres généraux”.
Vérifier si les datasets et dictionnaires chargés sont tous utiles au formulaire
Un de debug est proposé dans la console pour récupérer ces informations, notamment debug.getDatasets() et debug.getDataset('mon_dataset').ToJSON() (voir l’article Outil de débogage côté client).
Nettoyer les formulaires
Ne garder que les champs réellement utilisés dans la datastructure ET le layout.
Navigation : ne pas recharger la mainframe
S’assurer de ne pas recharger la mainframe lors des redirection. Pour ce faire, privilégier l’utilisation du WidgetButton et n’utiliser le type de redirection “window” que si nécessaire.
Désactiver l’authentification par CPS si ce mode n’est pas nécessaire
L’authentification par CPS ajoute du temps de réponse.
Cette option peut-être désactivée en demandant l’intervention de l’infra (une issue pour un script dédié est créée).
Les outils pour pousser plus loin l’analyse
Exporter les requêtes d’un projet pour les analyser
Il est possible de récupérer toutes les requêtes SQL générées par les dataqueries d’un projet : Exporter du SQL depuis un dataquery.
Le fichier résultant peut être passé à un outil comme MySQL Workbench ou DBeaver pour faciliter leur analyse et repérer d’éventuelles améliorations.
Tester un dataquery en CLI pour l’analyser (retour, erreurs et temps d’exécution)
Pour vérifier le résultat d’un dataquery ou connaître son temps d’exécution, il est également possible de l’exécuter en CLI. La procédure à suivre est disponible dans l’article Exécuter un dataquery.
Cette commande renvoie également la requête SQL effectuée et les erreurs rencontrées s’il y en a.
Identifier les requêtes les plus coûteuses
Pour identifier les requêtes les plus longues, il existe un mode slow_query_log dans MySQL. Une fois activé MySQL va logger, dans un fichier de log spécifique (mysql-slow.log), les requêtes dont le temps d’exécution dépasse le temps défini par la variable MySQL long_query_time.
Le fichier de log est peu lisible mais des outils d’analyse existent pour en extraire les informations pertinentes, tels que mysqldumpslow (fourni avec MySQL) ou pt-query-digest (recommandé).
Effectuer un profilage de l’application via XHProf pour une analyse approfondie
Une documentation ainsi qu’un exemple d’utilisation sont disponibles dans le wiki de framework : XHProf
Les bonnes pratiques pour les dataqueries
Les dataqueries doivent respecter les bonnes pratiques SQL (limiter les fonctions de tri au strict nécessaire, ne pas faire de jointure sur des variables de types différent, etc.), et éviter certaines erreurs courantes comme utiliser une variable calculées dans une condition, laisser un dataquery en mode “rw”, etc.
En cas de doutes sur les bonnes pratiques à appliquer pour éviter des requêtes inutilement coûteuses, s’adresser au DBA.