• Accueil / Salesforce / Été 20 après…
, Été 20 après la sauvegarde des flux et du temps CPU<span class="wtr-time-wrap after-title"><span class="wtr-time-number">4</span> minutes de lecture</span>

Été 20 après la sauvegarde des flux et du temps CPU4 minutes de lecture


, Été 20 après la sauvegarde des flux et du temps CPU<span class="wtr-time-wrap after-title"><span class="wtr-time-number">4</span> minutes de lecture</span>


introduction

(Soyez honnête, vous saviez que celui-ci allait arriver)

Summer 20 voit plus #LowCodeLove avec l’introduction de flux qui s’exécutent après l’enregistrement des enregistrements. Après le plaisir et les jeux, lorsque j’ai écrit un article comparant avant de sauvegarder le flux et les performances du déclencheur apex, puis un suivi détaillant ce que je pensais réellement se passer, j’avais hâte de mettre la main dessus pour voir si quelque chose était différent. Parce que j’aime discuter avec les gens sur Twitter. Cela a duré des jours la dernière fois.

Exemple de flux

Mon exemple de flux était encore une fois d’une simplicité rafraîchissante – lorsqu’une opportunité est insérée, mettez à jour un champ sur le compte associé appelé Opportunité la plus récente avec l’ID du nouvel enregistrement – il devait donc s’agir d’un flux après sauvegarde car l’ID d’enregistrement devait être renseigné. Aux fins du test, j’ai également supposé que la recherche de compte serait toujours renseignée sur l’opportunité.

, Été 20 après la sauvegarde des flux et du temps CPU<span class="wtr-time-wrap after-title"><span class="wtr-time-number">4</span> minutes de lecture</span>

Comme auparavant, j’ai baissé le niveau du journal, exécuté mon apex anonyme pour insérer mille opportunités réparties sur cinq comptes, puis les supprimer, et vérifié le fichier journal.

Si ce que je cherchais était plus de confusion et peut-être de controverse, je n’ai pas été déçu:

, Été 20 après la sauvegarde des flux et du temps CPU<span class="wtr-time-wrap after-title"><span class="wtr-time-number">4</span> minutes de lecture</span>

Comme ce n’était pas mon premier rodéo, j’ai ensuite mis l’insertion / suppression des mille enregistrements dans une boucle et j’ai continué à augmenter les itérations – en commençant par 1, juste au cas où cela changerait les choses.

  • Pas de boucle (scénario ci-dessus) – 0
  • 1 x – 0
  • 2 x – 6869
  • 3 x – Limite CPU dépassée – 19696

Donc, à moins que nous n’obtenions un millier d’itérations gratuites, les milliers suivants sont chers, et lorsque les milliers suivants sont extrêmement chers, je dirais que la journalisation du processeur est également désactivée pour les flux de sauvegarde après.

J’ai ensuite ajouté une seule ligne d’apex à la fin du code exécuté de manière anonyme:

Long newTime=Limits.getCPUTime();

Cela a radicalement changé les choses:

  • Pas de boucle – 6865
  • 1 x – 7115
  • 2 x – Temps CPU dépassé – 15779

Maintenant, cela pourrait être interprété que l’obtention du temps processeur consommé à ce jour via la méthode Limits.getCPUTime est incroyablement cher, mais en les ajoutant à l’intérieur des différentes boucles, j’ai dû insérer les données a donné une augmentation de quelques millisecondes, ce qui peut être en toute sécurité exclu.

Conclusion

Rien de ce que j’ai vu dans cette dernière expérience n’a changé mon point de vue selon lequel le processeur est consommé dans l’automatisation des flux, mais il n’est suivi que lors de l’accès. Il y a cependant un problème supplémentaire, en ce sens que je semble être en mesure de faire plus de travail si je ne fais pas le suivi du processeur – je peux terminer avec succès les deux mille insertions dans ce scénario, plutôt que de dépasser le temps CPU assez spectaculairement quand je le traque.

Cela a du sens pour moi, car le processeur n’est pas une limite stricte – vous pouvez la dépasser tant que l’infrastructure Salesforce a la capacité de le gérer, donc il y a une vérification autour du processeur utilisé et si cela ne va pas, la transaction sera autorisé à aller un peu plus loin qu’il ne le pourrait autrement. Cela pourrait aussi être une coïncidence, car la taille des pointes autorisées varie constamment, et je suis peut-être très proche de réussir dans les cas où je brèche, mais j’ai relancé mes tests plusieurs fois avec à peu près les mêmes résultats.

Bien sûr, je ne pense pas vraiment avoir besoin de plus de travail, je profite de ce qui ressemble à une lacune dans le suivi du processeur dans certaines circonstances. Ce serait une décision courageuse (de Oui, Monsieur le Ministre – une décision courageuse vous coûtera quelques voix, une décision courageuse vous fera perdre les élections!) pour mettre en production quelque chose qui en dépendait – une seule ligne d’Apex ajoutée quelque part dans la transaction la ferait sortir de l’eau, et je suis sûr qu’à un moment donné, Salesforce corrigera cela, et j’espère que certains des autres Surveillance du CPU!

J’aimerais aussi vraiment voir une partie de la journalisation que Salesforce capture en interne – la conjecture est très amusante, mais ce serait bien de comprendre ce qui se passe réellement.

Articles Similaires





Source de l’article traduit automatiquement en Français

Besoin d'aide ?
Voulez-vous utiliser Pardot à sa capacité maximale et avoir
+ DE LEADS QUALIFIÉS

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

Fermer