• Accueil / Salesforce / Utiliser le détecteur…
, Utiliser le détecteur de performances des requêtes Salesforce pour vérifier la dégradation<span class="wtr-time-wrap after-title"><span class="wtr-time-number">1</span> minutes de lecture</span>

Utiliser le détecteur de performances des requêtes Salesforce pour vérifier la dégradation1 minutes de lecture


Écrit à l’origine par Esteve Graells au Forcegraells.

Si nous examinons la rubrique Optimisation des requêtes dans Salesforce, nous découvrons l’un des problèmes les plus évidents de tout projet : le dégradation de la performance des éléments qui interrogent les données dans Salesforce.

, Utiliser le détecteur de performances des requêtes Salesforce pour vérifier la dégradation<span class="wtr-time-wrap after-title"><span class="wtr-time-number">1</span> minutes de lecture</span>

C’est-à-dire qu’à mesure que notre organisation grandit, les requêtes que nous avons initialement conçues (qui peuvent être optimisées, ou peut-être pas) peuvent subir une dégradation. Mais, je ne parle pas seulement des requêtes des développeurs avec SOQL – je parle des vues de liste, des rapports et des tableaux de bord que les utilisateurs utilisent pour exécuter des requêtes. De plus, cette dégradation se fait silencieusement, inaperçue, et n’est visible qu’avec des incidents de performances en Production, alors qu’il est déjà trop tard ! A ce stade, les actions correctives (création d’index, réorganisation des données, etc.) ne seront pas immédiates.

Pour vous assurer d’obtenir ces informations simplement, j’ai créé un outil nommé Détecteur de performances de requête.

Cet outil vous permet de vérifier comment Salesforce Optimizer évalue les ListViews, les rapports et les tableaux de bord :

  • Son coût
  • Le nombre de lignes renvoyées
  • Le plan d’accès
  • Avec les données présentes dans l’Org

Il met en évidence ceux qui ont un coût non sélectif, afin que vous les optimisiez en priorité, surtout s’ils ont un volume d’enregistrements très important. Ils constituent votre objectif d’optimisation le plus important, car ce sont ceux que les utilisateurs ont utilisés.

Avec ces informations, nous pouvons :

  1. Détectez les requêtes qui ne sont pas efficaces, et rendez-les efficaces immédiatement, car si le volume est élevé, le coût le sera aussi.
  2. Consultez l’historique des performances et évaluez celles qui s’aggravent pour démarrer le processus d’optimisation.
  3. Obtenez la liste des Requêtes SOQL, pour savoir où concentrer nos efforts d’optimisation.

Par conséquent, nos efforts d’optimisation seront immédiatement apparents du point de vue de vos utilisateurs. Dans la suite de cet article, je décrirai les caractéristiques et les composants de l’outil.

introduction

Les principales caractéristiques techniques du Détecteur de performances de requête sont:

  • 100% Apex et VisualForce (j’ai encore besoin d’en savoir plus sur Lightning !)
  • Crée 1 objet pour enregistrer l’historique des résultats
  • Tous les processus de calcul sont Batchable afin que leur exécution interfère avec le travail des autres
  • Les objets internes de Salesforce sont interrogés et l’API Tooling est invoquée

Fondamentalement, ce que j’ai fait a été d’utiliser des composants/fonctionnalités/données qui existent déjà au sein de la plate-forme Salesforce et de les mettre au travail pour résoudre le problème, démontrant encore une fois la grande polyvalence et la grande puissance dont nous disposons.

Objets créés

Je n’ai utilisé que 2 objets :

  1. QueryCostHistory__c: qui stocke les résultats des scans de tous les objets, qu’il s’agisse de List Views, de Rapports, de Dashboards ou de recherche de User Logs à la recherche de SOQL Requêtes
  2. Process_Log__c: qui me permet de récupérer des traces que je ne souhaite pas afficher ou qui ne sont pas affichées dans le Log Salesforce

Pour des outils comme celui-ci, je pense qu’il est important de créer le moins d’objets supplémentaires.

Classes et pages VisualForce

L’ensemble des classes et pages que j’ai créé :

  • 4 pages VisualForce
  • 11 classes APEX

Schéma d’exécution

Le schéma d’exécution est très simple :

  • Depuis le contrôleur principal QP_MainController, les autres contrôleurs sont appelés pour obtenir les informations. Chaque contrôleur obtient la liste des objets qu’il gère (ListViews, Reports, etc.) dans la période choisie par l’utilisateur, et la dépose en attente d’analyse dans le QueryCostHistory__c objet
  • Le controlle QP_ToolingAPIRequester est chargé d’appeler l’API Tooling pour obtenir les plans de requête, en parcourant la table à la recherche de ceux en attente. Il invoque l’API pour obtenir avec des lots et enregistre les résultats dans le même objet.
    • Les contrôleurs qui effectuent des recherches d’éléments sont appelés QP_GetLast *
  • Par la suite, les contrôleurs et les pages détaillées et historiques de VisualForce sont chargés de montrer respectivement à l’utilisateur les résultats individuels et cumulés.
    • Les contrôleurs qui affichent les données sont les soi-disant QP_Afficher *
  • Enfin, il existe 2 objets pour prendre en charge le stockage de données dans des listes

Caractéristiques à souligner

Objets internes

TPour obtenir les informations des ListViews, Rapports, Tableaux de bord utilisés dans une période, les tables internes sont consultées, aucune nouvelle donnée n’est créée ni des choses étranges ne sont faites.

Tous les processus mettent en œuvre le @Batchable : unComme je l’ai mentionné plus tôt, je suis obsédé par le fait que le travail des utilisateurs n’est pas affecté par les outils que j’utilise, et je ne veux pas que les limites soient affectées – alors, j’utilise le @Batchable l’interface et l’exécution segmentée à l’aide de morceaux, qui est un paramètre de la Database.ExecuteBatch méthode. Ainsi, quelle que soit l’importance des volumes, les exécutions ne dépassent jamais les limites et la consommation de ressources de la Flex Queue et des files asynchrones est minime (qui sont toujours moins prioritaires que la consommation synchrone, bien sûr).

Exécution parallèle

Scomme j’utilise des ressources asynchrones, cela me permet de lancer les requêtes en parallèle. Si nous prévoyons (par @Programme) le processus tous les soirs, par exemple, vous pouvez lancer les processus simultanément, en consommant 1/4 du temps que vous consommeriez si vous deviez les lancer l’un après l’autre.

Envoi de notifications

Je n’ai pas mis en œuvre non plus le @Programmable interface ou un système d’avertissement, car je ne voulais pas étendre le code inutilement, et le garder lisible. Vous pouvez déjà découvrir comment le faire en toute sécurité, car il y a beaucoup de documentation disponible ; cependant, il suffit de simplement mettre en œuvre le @Programmable interface dans les contrôleurs. Pour générer des événements et des alertes, chaque enseignant a ses méthodes et ses préférences…

Conclusion

Grâce à ma connaissance de la plate-forme, j’ai pu l’étendre pour créer des fonctionnalités qui résolvent des problèmes évidents dans toute organisation qui développe ou modifie des données. L’outil garantit qu’il n’y a pas de risque d’incidents de production difficiles à diagnostiquer – et cela pourrait vous sauver la tête à l’avenir !

Le code complet de cet outil est disponible dans ce Bitbucket référentiel, afin que vous puissiez l’utiliser comme vous le souhaitez et l’améliorer.

J’espère que ça aide !

, Utiliser le détecteur de performances des requêtes Salesforce pour vérifier la dégradation<span class="wtr-time-wrap after-title"><span class="wtr-time-number">1</span> minutes de lecture</span>



Source de l’article traduit automatiquement en Français

Besoin d'aide ?
Vous utilisez Pardot depuis un certain temps mais vous n'êtes pas sûr d'en
exploiter tout le potentiel

Notre analyse de votre Pardot offerte dès aujourd'hui
Merci, vous pouvez compléter notre questionnaire
Nous allons revenir vers vous rapidement !

Fermer