Codage plus efficace pour éviter le « Dépassement de la limitation de temps processeur Apex »

Nous comptons uniquement les événements qui nécessitent l’utilisation processeur du serveur d’applications. Nous ne comptons pas certains éléments utilisant l’UCT du serveur d’applications. En effet, ils sont hors de notre contrôle en tant que programmeurs. Par exemple, le temps passé dans la base de données à récupérer des enregistrements ne comptera pas, ni le temps passé à attendre le retour d'un appel. Nous ne comptons pas le temps passé à compiler votre code car vous ne le contrôlez pas.
 

Nous comptons presque tout ce qui se passe sur le serveur d’applications, y compris les actions déclaratives. Si DML dans votre code rencontre une règle de validation avec une formule, nous compterons le temps consacré à l’évaluation de cette formule. Le temps processeur est calculé pour toutes les exécutions sur les serveurs d’applications Salesforce se produisant dans une transaction Apex—pour le code Apex en cours d’exécution et pour tous les processus appelés de ce code, tels que le code de package et les workflows. Le temps processeur est privé pour une transaction et est isolé des autres transactions. Les opérations qui ne consomment pas le temps processeur des serveurs d’applications ne sont pas comptés dans le temps processeur.
 

Ce qui est compté

• Tout le code Apex
• Fonctions de bibliothèque exposées dans Apex
• Exécution de workflow

Ce qui n’est pas compté

• Opérations de la base de données, comme par exemple, la portion de la durée de l'exécution dans la base de données pour DML, SOQL, et SOSL n’est pas comptée, ni le délai d'attente pour les appels Apex., SOQL

Meilleures pratiques pour réduire le temps processeur

Vous pouvez consulter Meilleures pratiques du code Apex  pour réduire le temps processeur. Nous allons passer en revue les suggestions ci-dessous. 

Utilisation d'une requête basée sur le mappage

List<Account> lstacc=[Select Id from Account limit 10000]; Set<Id> setIds=new Set<Id>(); for(Account a:lstacc){ //More CPU time for sure due to looping setIds.add(a.id); } //Using Map query saves CPU time //Fetching all account in map Map<id,account> aMap = new Map<id,account>([Select Id,Name from Account limit 50000]); //Creating list of accounts List<account> accList = aMap.values() ; //Creating set of ids Set<id> accIds = aMap.keySet() ;

Découvrez si votre entreprise vous permet d’effectuer l’opération de manière asynchrone

Dans certains cas, le processus métier peut ne pas être en temps réel. S’il est possible de faire exécuter le code @future, le contexte sera rompu et le délai d’expiration du processeur pour le processus asynchrone est de 60 secondes (6x le processus synchrone). Pensez-y si vous risquez d’atteindre la limite.

Utilisation globale de SOQL

Étant donné que le temps de la base de données n’est pas calculé en temps processeur, il est toujours préférable d’explorer l’utilisation de SOQL global pour votre cas d’utilisation professionnel.

Supposons que vous souhaitez obtenir la valeur de champ de certains enregistrements. Si vous utilisez normal en boucle pour obtenir ces éléments évidents, vous avez utilisé votre temps processeur. Essayez plutôt d’envoyer automatiquement votre calcul à l’aide des fonctions globales SUM, AVG au niveau de la couche de base de données afin de réduire le temps processeur et d’envoyer automatiquement le processus sur la couche de base de données elle-même. Explorez les options permettant de regrouper ou de créer une sorte de filtrage au niveau de la couche de base de données. Envoyez automatiquement vos calculs sur la couche de base de données pour réduire les risques de problèmes de délai d’expiration du processeur.

Prenez uniquement les données nécessaires et exécutez une boucle

Cela est essentiel pour ne filtrer que les données spécifiques sur une liste d’enregistrements car trop de boucles augmenteront le temps processeur. Il en était de même lorsque le nombre d’instructions de script était limité.

Remarque : Il existe actuellement un problème connu avec les opérations d'insertion DML qui imposent CPU Apex sur un grand nombre d’enregistrements ayant trop de colonnes.