• Accueil / Salesforce / Blog de Bob…
, Blog de Bob Buzzard: L&rsquo;impact de System.debug<span class="wtr-time-wrap after-title"><span class="wtr-time-number">2</span> minutes de lecture</span>

Blog de Bob Buzzard: L’impact de System.debug2 minutes de lecture


, Blog de Bob Buzzard: L&rsquo;impact de System.debug<span class="wtr-time-wrap after-title"><span class="wtr-time-number">2</span> minutes de lecture</span>

TL; DR

Vos instructions System.debug consomment des ressources même lorsque vous ne capturez pas les journaux de débogage.

Si vous passez des paramètres de type de données complexes à System.debug, ils consommeront plus de ressources, car ils seront convertis en chaînes (avant d’être supprimés car vous ne capturez pas les journaux de débogage!)

introduction

Cette semaine, les développeurs Salesforce de Londres ont accueilli Paul Battisson et son tour
jusqu’à 11 – Amélioration des performances de votre conversation sur le code Apex, ce qui a rappelé
moi de quelque chose qui a été sur ma liste de choses à examiner – l’impact de
Instructions System.debug sur votre code.

Dans l’exposé de Paul, il souligne que le fait de mesurer le temps CPU consommé
et l’écriture de la métrique dans le journal de débogage consomme une petite quantité de temps CPU.
Et de nombreux développeurs Apex savent que l’activation de la journalisation du débogage dans Salesforce
impacte la durée d’une transaction, parfois de manière significative si le débogage
log génère plusieurs mégaoctets d’informations – laissez simplement le développeur
console ouverte pendant que vous utilisez votre application lourde de code si vous ne l’avez pas fait
expérimenté cela.

Ce que l’on sait moins, c’est que les instructions System.debug ont un impact sur votre
transactions même si vous ne capturez pas les journaux de débogage, car je m’efforcerai de
montrer dans le reste de ce blog.

Méthodologie

J’ai une classe Apex simple avec une méthode statique qui boucle 5000 fois,
incrémenter un index de 0 à 4999. Une chaîne qui commence la vie vide a
l’index concaténé avec lui à chaque fois dans la boucle, en utilisant le +
opérateur.

Au début de la méthode, l’heure actuelle en millisecondes et le temps CPU
consommés sont capturés, et à la fin de la méthode, cela est répété et le
différence (les millisecondes écoulées et le temps CPU consommé pour la méthode) sont
stocké dans un objet personnalisé.

public class LoggingOn 
{
    public static void LoggingOn()
    {
        Limits_Consumed__c lc=new Limits_Consumed__c();
        Long startMillis=System.now().getTime();
        Long startCPU=Limits.getCpuTime();
        
        String message='';
        for (Integer idx=0; idx

Les tests

Pour chaque test, la méthode a été exécutée deux fois:

  1. Via exécution anonyme via la console développeur, avec la journalisation du débogage activée
    et le niveau de journalisation à la valeur par défaut de SFDC_DevConsole.

  2. En tant que seul code dans un déclencheur avant la mise à jour d'un enregistrement (c'était le
    moyen le plus rapide pour exécuter l'Apex en dehors de l'exécution anonyme - le
    le déclencheur est essentiellement un transporteur pour cela) avec la journalisation du débogage désactivée

1. Aucune instruction de débogage

Le scénario 1 a duré 387 millisecondes et a consommé 154 millisecondes de
CPU

Le scénario 2 a duré 44 millisecondes et a consommé 45 millisecondes de
CPU

J'ai ensuite ajouté des instructions de débogage et exécuté la méthode via les deux scénarios.

2. Ajout d'une instruction de débogage

Cela a utilisé System.debug pour enregistrer la variable de message à chaque fois dans la boucle:

System.debug('Message = ' + message);

Le scénario 1 a duré 736 millisecondes et a consommé 285 millisecondes de
CPU - vous pouvez clairement voir l'impact des instructions de débogage lors de la journalisation
activé ici.

Le scénario 2 a pris 49 millisecondes de temps écoulé et 45 millisecondes de CPU - très
peu de changement ici.

3. Extension de l'instruction de débogage

L'instruction de débogage a été étendue pour inclure le nom de l'utilisateur actuel:

System.debug('Message = ' + message + ', User ' + UserInfo.getName());

Le scénario 1 a pris 1281 millisecondes de temps écoulé et consommé
328 millisecondes de CPU. Un aspect intéressant ici est qu'après une très
courte période de temps, l'aspect du message était tronqué et l'utilisateur
le nom n'apparaissait pas, mais le travail était toujours en cours pour le récupérer et
construire la chaîne de débogage complète à chaque fois dans la boucle.

Le scénario 2 a duré 120 millisecondes et 109 millisecondes
du CPU - commence à monter en puissance.

4. Inclure un sObject

Au début de la méthode, avant le démarrage de la CPU et le temps écoulé
capturé, un enregistrement de compte avec quatre champs (Id, Nom, AccountNumber,
CreatedDate) a été récupéré de la base de données. Cela a été ajouté au débogage
déclaration:

System.debug('Message = ' + message + ', User ' + UserInfo.getName() + ', Account = ' + acc);

Le scénario 1 a pris 1504 millisecondes de temps écoulé et consommé
494 millisecondes de CPU, mais encore une fois la plupart du temps l'enregistrement du compte
les détails n'étaient pas écrits dans le journal.

Le scénario 2 a pris 185 millisecondes de temps écoulé et 180 millisecondes de processeur
- une augmentation d'environ 50%.

5. Division en plusieurs instructions de débogage

Pour s'assurer que les informations peuvent être vues dans les journaux de débogage, le seul
déclaration a été scindée en trois:

System.debug('Message = ' + message);
System.debug('User = ' + UserInfo.getName());
System.debug('Account = ' + acc);

Le scénario 1 a pris 1969 millisecondes de temps écoulé et consommé
656 millisecondes de CPU, et cette fois toutes les informations pertinentes
a été enregistré à chaque fois.

Le scénario 2 a duré 198 millisecondes et 192 millisecondes
de CPU - une petite augmentation.

6. Ajout d'un tableau

La requête pour récupérer l'enregistrement a été étendue pour inclure l'ID, le sujet et
Description de ses 2 cas associés, et une instruction supplémentaire ajoutée au débogage
cette:

System.debug('Message = ' + message);
System.debug('User = ' + UserInfo.getName());
System.debug('Account = ' + acc);
System.debug('Cases = ' + acc.cases);

Le scénario 1 a pris 2563 millisecondes de temps écoulé et consommé
1136 millisecondes de CPU - se rapprochant du double du CPU, donc clairement
la journalisation d'un tableau a un impact considérable.

Le scénario 2 a duré 368 millisecondes et 353 millisecondes
de CPU, encore une fois proche du double.

Revoir les chiffres

Voici les numéros des tests dans un format facile à consommer, avec le
augmentation en pourcentage par rapport au test précédent indiqué entre parenthèses.

TestÉcoulé 1CPU 1Écoulé 2CPU 2
13871544445
2736 (47%)285 (46%)49 (11%)45 (0%)
31281 (60%)328 (15%)120 (144%)109 (142%)
41504 (17%)494 (50%)185 (54%)180 (65%)
51969 (31%)656 (33%)198 (7%)192 (7%)
62563 (30%)1136 (73%)368 (86%)353 (84%)

En regardant les résultats du scénario 1, nous pouvons voir que le temps augmente avec le
nombre d'instructions de débogage et complexité des types de données. Cela rend parfait
sens que je fais plus de travail pour trouver des détails granulaires sur l'état comme
la méthode se poursuit.

En regardant les résultats du scénario 2, nous pouvons voir qu'en ne capturant pas le débogage
journaux, les nombres sont beaucoup plus petits. Cependant, le temps augmente à mesure que
le nombre d'instructions de débogage et la complexité des types de données augmentent, même si je n'utilise aucune des informations.

En quittant les instructions de débogage, je force la conversion de divers types de données
aux chaînes afin de les passer en paramètres à la méthode System.debug (),
qui ne fera rien avec eux. Dans le cas du test 6, mon
la transaction dure plus d'un tiers de seconde en raison d'un travail
n'ajoute aucune valeur - mes utilisateurs seront ravis!

Supprimer tous les débogages?

Il en va de même pour la solution pour supprimer toutes les instructions de débogage avant de déployer sur
production? Dans de nombreux cas, oui. Les instructions System.debug () sont souvent des restes
des problèmes rencontrés pendant le développement et peuvent être supprimés en toute sécurité. Mais
pas dans tous les cas.

Si vous essayez de localiser un problème intermittent, peut-être pas. Ça pourrait
être utile d'avoir les instructions de débogage là-dedans afin que vous puissiez rapidement activer
journalisation pour l'utilisateur ayant le problème et voir exactement ce qui se passe. le
l'inconvénient est que la transaction est ralentie pour tout le monde tout le temps,
pas seulement l'utilisateur qui rencontre le problème lorsqu'il le rencontre.

Une meilleure solution peut être de permettre à l'administrateur système de contrôler si
les instructions System.debug () sont exécutées via la configuration. De cette façon
ils sont là si nécessaire, mais ne sont exécutés qu'en cas de problème
traqué.

Pour effectuer un test assez brutal de cela, j'ai créé un type de métadonnées personnalisé
avec une case à cocher pour indiquer si le débogage est activé. Le type de métadonnées personnalisées
est récupéré une fois que le temps de démarrage écoulé et le temps CPU ont été capturés, et
est vérifié avant que chacune des instructions de débogage ne soit exécutée, pour essayer de simuler
un peu du monde réel. Ma méthode se présente maintenant comme suit:

public class LoggingOn 
{
	public static void LoggingOn()
    {
        Account acc=[select id, name, accountnumber, createddate,
                     (select id, subject, description from Cases)
                      from account where id='0011E00001ogFnaQAE'];
                      
        Limits_Consumed__c lc=new Limits_Consumed__c();
        Long startMillis=System.now().getTime();
        Long startCPU=Limits.getCpuTime();
        
        Debugging__mdt systemDebugging=Debugging__mdt.getInstance('System');
        String message='';
        for (Integer idx=0; idx

La réexécution des tests finaux avec le type de métadonnées personnalisé défini pour désactiver les instructions de débogage a montré une amélioration significative:

Le scénario 1 a pris 475 millisecondes de temps écoulé (-78%) et a consommé 213 millisecondes de processeur (-81%)

Le scénario 2 a pris 66 millisecondes de temps écoulé (-82%) et a consommé 62 millisecondes de processeur (-82%)

Conclusion

Maintenant, je ne suggère pas que tout le monde commence à créer des cadres de configuration pour permettre l'activation ou la désactivation des instructions de débogage individuelles pour des utilisateurs spécifiques - pour toute implémentation Salesforce de taille décente, ce serait une énorme quantité de travail et un casse-tête de maintenance continu. Ce que je dis, c'est de penser aux instructions de débogage que vous laissez dans votre code lorsque vous déployez votre code en production. Bien que vous n'ayez pas l'impression d'avoir à vous soucier de quelques instructions qui déboguent les détails des enregistrements, une fois que vous commencez à mettre à l'échelle le volume, cela peut ralentir l'expérience utilisateur. Des études ont montré que lorsqu'une application est lente, les utilisateurs la perçoivent également comme boguée, que ce soit effectivement le cas ou non - une fois qu'un utilisateur prend contre votre application, il fait tout!





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