Compréhension des limitations et des gouverneurs d'exécution

Comme le langage Apex est exécuté dans un environnement mutualisé, le moteur d'exécution Apex applique une limitation stricte pour empêcher qu'un emballement de code Apex ne monopolise des ressources partagées. Ces limitations, ou gouverneurs, surveillent et appliquent les statistiques présentées dans le tableau suivant. Si un code Apex dépasse une limite, le gouverneur associé génère une exception à l'exécution qui ne peut pas être gérée.

Les limitations du gouverneur s'appliquent à l'ensemble de l'organisation, ainsi qu'à des espaces de noms spécifiques. Par exemple, si vous installez un package géré créé par un FAI partenaire de salesforce.com à partir de Force.com AppExchange, les composants du package appartiennent à un espace de noms unique par rapport à d'autres composants dans votre organisation. Par conséquent, tout code Apex inclus dans un package peut générer jusqu'à 150 instructions DML pendant l'exécution. De plus, tout code Apex natif de votre organisation peut générer jusqu'à 150 instructions DML, ce qui signifie que plus de 150 instructions DML peuvent être exécutées durant une demande unique si un code du package géré et un code de votre organisation native sont exécutés. Inversement, si vous installez un package à partir d'AppExchange qui n'est pas créé par un FAI partenaire de salesforce.com, le code de ce package n'inclut pas son propre décompte séparé de limitations du gouverneur. Toutes les ressources qu'il utilise sont prises en compte dans le total de votre organisation. Les messages de ressources cumulées et les e-mails d'avertissement sont également générés sur la base des espaces de noms du package géré. Pour plus d'informations sur les packages de FAI partenaires de salesforce.com, reportez-vous à Programmes partenaires salesforce.com.

Description	Limitation
Nombre total de requêtes SOQL émises¹	100
Nombre total de requêtes SOQL émises pour des méthodes Apex par lot et futures¹	200
Nombre de total d'enregistrements récupérés par des requêtes SOQL	50 000
Nombre total d'enregistrements récupérés par `Database.getQueryLocator`	10 000
Nombre total de requêtes SOSL émises	20
Nombre de total d'enregistrements récupérés par une seule requête SOQL	200
Nombre total d'instructions DML émises²	150
Nombre total d'enregistrements traités suite à des instructions DML, `Approval.process` ou `database.emptyRecycleBin`	10 000
Nombre total d'instructions de code exécutées	200 000
Nombre total d'instructions de code exécutées pour des méthodes Apex par lot et futures	1 000 000
Taille totale du segment mémoire³	6 Mo
Taille totale du segment mémoire pour les méthodes Apex par lot et futures	12 Mo
Profondeur totale de la pile pour toute invocation Apex qui active récursivement des déclencheurs en raison d'instructions `insert`, `update` ou `delete`⁴	16
Taille par lot de la liste de boucles For	200
Nombre total d'appels (demandes HTTP ou appels de services Web) dans une demande	10
Délai d'expiration maximal de tous les appels (demandes HTTP ou appels de services Web) dans une demande	120 secondes
Délai d'expiration par défaut des appels (demandes HTTP ou appels de services Web) dans une demande	10 secondes
Nombre total de méthodes avec l'annotation `future` autorisées par invocation Apex⁵	10
Taille maximale de demande ou de réponse d'appel (demande HTTP ou appel de service Web)⁶	3 Mo
Nombre total de méthodes `sendEmail` autorisées	10
Nombre total d'informations describe autorisées⁷	100
Nombre total de classe qui peuvent être planifiées simultanément	25
Nombre total de classes de test qui peuvent être mises en file d'attente par période de 24 heures⁸	La valeur la plus grande entre 500 et 10 multiplié par le monde de classes de test dans l'organisation

¹ Dans une requête SOQL avec des sous-requêtes de relation parent-enfant, chaque relation parent-enfant est considérée comme une requête supplémentaire. Ces types de requête sont limitées à trois fois le nombre de requêtes de niveau supérieur. Le nombre de lignes de ces requêtes relationnelles est pris en compte dans le nombre de lignes de l'exécution globale du code. En plus des instructions SOQL statiques, les appels aux méthodes suivantes sont prises en compte dans le nombre d'instructions SOQL émises dans une demande.

Database.countQuery
Database.getQueryLocator
Database.query

² Les appels aux méthodes suivantes sont pris en compte dans le nombre de requêtes DML émises dans une demande.

Approval.process
Database.convertLead
Database.emptyRecycleBin
Database.rollback
Database.setSavePoint
delete et Database.delete
insert et Database.insert
merge
undelete et Database.undelete
update et Database.update
upsert et Database.upsert
System.runAs

³ La taille du segment mémoire des services de messagerie st de 36 Mo.

⁴ Un code Apex récursif qui n'active aucun déclencheur avec des instructions insert, update ou delete existe dans une invocation unique, avec une pile unique. Inversement, un code Apex unique qui active un déclencheur engendre le déclencheur dans une nouvelle invocation Apex, séparée de l'invocation du code qui a activé le déclencheur. Comme la génération d'une nouvelle invocation de code Apex est une opération plus coûteuse qu'un appel récursif dans une invocation unique, les restrictions sur la profondeur de la pile de ces types d'appel récursif sont plus élevées.

⁵ Salesforce impose également une limite sur le nombre d'invocations de méthode future : 200 appels de méthode par licence utilisateur Salesforce complète, licence utilisateur Salesforce Platform ou licence utilisateur Force.com App Subscription, par 24 heures. Cette limitation s'applique à l'échelle de l'organisation. Les licences utilisateur Chatter Only, Utilisateurs clients de Chatter, Customer Portal User et Partner portal ne sont pas incluses dans le calcul de cette limitation. Par exemple, supposons que votre organisation possède trois licences Salesforce complètes, deux licences Salesforce Platform et 100 licences Customer Portal User. Votre organisation entière est limitée à 1000 appels de méthode par 24 heures, calculés par la formule 200 * (3+2), pas 200 * (3+2+100).

⁶ Les tailles des demandes et des réponses HTTP sont prises en compte dans la taille totale du segment mémoire.

⁷ Les informations describe comprennent les méthodes et les objets suivants :

Objets ChildRelationship
Objets RecordTypeInfo
Objets PicklistEntry
Appels fields
Appels fieldsets

⁸ Cette limite s'applique lorsque vous lancez des tests asynchrones en sélectionnant des classes de test pour l'exécution via la page Exécution du test Apex.

Des limitations s'appliquent individuellement à chaque testMethod.

Utilisez les méthodes Limits pour déterminer les limites d'exécution de votre code pendant son exécution. Par exemple, vous pouvez utiliser la méthode getDMLStatements pour déterminer le nombre d'instructions DML qui ont déjà été appelées par votre programme, ou la méthode getLimitDMLStatements pour déterminer le nombre total d'instructions DML disponibles pour votre code.

Pour de meilleures performances, les requêtes SOQL doivent être sélectives, notamment pour les requêtes dans des déclencheurs. Pour éviter les délais d'exécution importants, les requêtes SOQL non sélectives peuvent être terminées par le système. Les développeurs reçoivent un message d'erreur lorsqu'une requête non sélective dans un déclencheur est exécutée sur un objet qui contient plus de 100 000 enregistrements. Pour éviter cette erreur, assurez-vous d'utiliser une requête sélective. Reportez-vous à Requêtes SOQL plus efficaces.

Pour un code Apex enregistré en utilisant l'API Salesforce.com version 20.0 ou antérieure, si un appel d'API active un déclencheur, le lot de 200 enregistrements à traiter est divisé en lots de 100 enregistrements. Pour un code Apex enregistré en utilisant l'API Salesforce.com versions 21.0 et supérieures, les lots d'API ne sont pas divisés. Notez que les valeurs de variable statique sont réinitialisées entre les lots, contrairement aux limitations du gouverneur. N'utilisez pas des variables statiques pour suivre les informations d'état entre les lots.

En plus des limitations du gouverneur d'exécution, le langage Apex comprend les limitations suivantes :

Le nombre maximal de caractères pour une classe est de 1 million.
Le nombre maximal de caractères pour un déclencheur est de 1 million.
Le volume maximal de code Apex utilisé dans une organisation est de 3 Mo.
Remarque
Cette limite ne s'applique pas aux packages gérés certifiés installés à partir d'AppExchange, (c.-à-d. une application marquée Certifiée AppExchange). Le code de ces types de package appartient à un espace de noms unique du code de votre organisation. Pour plus d'informations sur les packages certifiés AppExchange, reportez-vous à l'aide en ligne de Force.com AppExchange.
Cette limite ne s'applique à aucun code inclus dans une classe définie avec l'annotation @isTest.
La taille de la méthode est limitée. Les méthodes volumineuses qui dépassent la limite autorisée entraînent une exception à l'exécution de votre code. Comme dans Java, dans le langage Apex la limite de la taille de méthode est de 65 535 octets de bytecode d'instructions compilées.
Si une requête SOQL est exécutée pendant plus de 120 secondes, elle peut être annulée par Salesforce.
Chaque demande Apex est limitée à 10 minutes d'exécution.
Une demande d'appel est limitée à 20 demandes simultanées à des URL avec le même hôte. L'hôte est défini par le sous-domaine unique de l'URL, par exemple www.monsite.com et extra.monsite.com sont deux hôtes différents. La limite est calculée sur l'ensemble des organisations qui accèdent au même hôte. Si la limite est dépassée, une exception CalloutException est levée.
Le nombre maximal d'enregistrements qu'un rapport d'événement renvoie est de 20 000 pour un utilisateur non administrateur système et de 100 000 pour un administrateur système.
Chaque organisation a droit à 10 demandes synchrones simultanées pour des demandes longues dont l'exécution dépasse 5 secondes. Si des demandes supplémentaires sont effectuées alors que 10 longues demandes sont en cours d'exécution, elles sont refusées.
Un utilisateur peut avoir jusqu'à 50 curseurs de requête ouverts en même temps. Par exemple, si 50 curseurs sont ouverts et qu'une application cliente toujours connectée sous le même utilisateur tente d'en ouvrir un nouveau, le plus ancien des 50 curseurs est libéré. Notez que cette limitation est différente pour la méthode startApex, qui peut avoir jusqu'à cinq curseurs de requête ouverts à la fois par utilisateur. Les autres méthodes Apex par lot ont une limite plus élevée de 50 curseurs.
Les limitations en curseur des différentes fonctionnalités Force.com sont suivies séparément. Par exemple, vous pouvez avoir 50 Apex curseurs de requête, 50 curseur par lot et 50 curseurs Visualforce ouverts en même temps.
Dans une transaction unique, vous pouvez référencer uniquement 10 espaces de noms uniques. Par exemple, supposons que vous avez un objet qui exécute une classe dans un package géré lors de la mise à jour de l'objet. Ensuite, cette classe met à jour un deuxième objet, qui à son tour exécute une classe différente dans un package différent. Bien que le deuxième package n'a pas été accédé directement par le premier, car il se produit dans la même transaction, il est inclus dans le nombre d'espaces de noms accédés dans une transaction unique.
Tout déploiement d'un code Apex est limité à 5000 unités de code de classes et de déclencheurs.
Si vous utilisez le produit Mise à jour Data.com et ses tâches automatisées, et que vous avez défini des déclencheurs Apex avec des requêtes SOQL qui s'exécutent sur des enregistrements de compte, de contact ou de piste, les requêtes peuvent interférer avec les tâches de Mise à jour de ces objets. Vos déclencheurs Apex (combinés) ne doivent pas dépasser 200 requêtes SOQL par lot. Sinon, votre tâche Mise à jour pour cet objet échoue. De plus, si vos déclencheurs appellent des méthodes future, ils sont soumis à une limite de 10 appels future par lot.

Limitations en e-mails

Limitations en e-mails entrants

Services de messagerie : Nombre maximal d'e-mails traités (inclut la limite pour E-mail vers requête à la demande)	Nombre de licences utilisateur multiplié par 1 000, jusqu'à un maximum de 1 000 000 par jour
Services de messagerie : Taille maximale d'un e-mail (corps et pièces jointes)	10 Mo¹
E-mail vers requête à la demande : Taille maximale d'une pièce jointe	10 Mo
E-mail vers requête à la demande : Nombre maximal d'e-mails traités (pris en compte dans la limitation des services de messagerie)	Nombre de licences utilisateur multiplié par 1 000, jusqu'à un maximum de 1 000 000 par jour

¹ La taille maximale des e-mails des services de messagerie varie en fonction de la langue et du jeu de caractères.

Lors de la définition de services de messagerie, notez les éléments suivants :

Un service de messagerie traite uniquement les messages qu'il reçoit à l'une de ses adresses.
Salesforce limite le nombre total de messages que tous les services de messagerie combinés, E-mail vers requête à la demande inclus, peuvent traiter quotidiennement. Les messages qui dépassent cette limite sont renvoyés, ignorés ou mis en file d'attente pour un traitement le jour suivant, en fonction de la configuration des paramètres de réponse d'échec de chaque service de messagerie. Salesforce calcule la limite en multipliant le nombre de licences utilisateur par 1 000, jusqu'à une valeur quotidienne maximale de 1 000 000. Par exemple, si vous avez 10 licences, votre organisation peut traiter jusqu'à 10 000 e-mails par jour.
Les adresses de services de messagerie que vous créez dans votre sandbox ne peuvent pas être copiées dans votre organisation de production.
Pour chaque service de messagerie, vous pouvez instruire Salesforce d'envoyer les messages d'erreur à une adresse spécifique au lieu de celle de l'expéditeur.
Les services de messagerie rejettent les e-mails et notifient l'expéditeur si l'e-mail (corps de texte, corps HTML et pièces jointes combinés) dépassent 10 Mo environ (selon la langue et le jeu de caractères).

E-mail sortant : Limitations pour les e-mails individuels et en masse envoyés en utilisant Apex

Vous pouvez envoyer des e-mails individuels au maximum à 1000 adresses e-mail externes par jour, en fonction de l'heure GMT. Les e-mails individuels envoyés en utilisant l'application ne sont pas pris en compte dans cette limite.

Vous pouvez envoyer des e-mails en masse à 1 000 adresses e-mail externes par organisation et par jour, en fonction de l'heure GMT. Le nombre maximum d'adresses externes que vous pouvez inclure dans chaque e-mail en masse dépend de l'édition Salesforce que vous utilisez :

Edition	Limitation en adresses par e-mails en masse
Professional	250
Enterprise Edition	500
Unlimited Edition	1000

Remarque

Notez les points suivants sur les limitation en e-mails :

Les limitations en e-mails individuels et en masse ne prennent pas en compte les adresses uniques. Par exemple, si vous avez 10 fois l'adresse alaindupond@exemple.com dans votre e-mail, 10 adresses sont prises en compte dans la limite.
Vous pouvez envoyer un nombre illimité d'e-mails à vos utilisateurs internes. Ces limites s'appliquent également aux e-mails envoyés à l'aide de l'API et d'Apex.
Dans les organisations Developer Edition et dans celles qui utilisent Salesforce pendant une période d'évaluation, votre organisation peut envoyer un e-mail en masse au maximum à 10 adresses e-mail externes par jour. Cette limitation inférieure ne s'applique pas si votre organisation a été créée avant la version Winter '12 et si elle a déjà activé les e-mails en masse avec une limitation supérieure.

Limitations du gouverneur pour une tâche Apex par lot

Notez les limitations du gouverneur suivantes pour une tâche Apex par lot :

Jusqu'à cinq tâches par lot en file d'attente ou actives sont autorisées pour Apex.
Un utilisateur peut avoir jusqu'à 50 curseurs de requête ouverts en même temps. Par exemple, si 50 curseurs sont ouverts et qu'une application cliente toujours connectée sous le même utilisateur tente d'en ouvrir un nouveau, le plus ancien des 50 curseurs est libéré. Notez que cette limitation est différente pour la méthode startApex, qui peut avoir jusqu'à cinq curseurs de requête ouverts à la fois par utilisateur. Les autres méthodes Apex par lot ont une limite plus élevée de 50 curseurs.
Les limitations en curseur des différentes fonctionnalités Force.com sont suivies séparément. Par exemple, vous pouvez avoir 50 Apex curseurs de requête, 50 curseur par lot et 50 curseurs Visualforce ouverts en même temps.
Un maximum de 50 millions d'enregistrements peuvent être renvoyés dans l'objet Database.QueryLocator. Si plus de 50 millions d'enregistrements sont renvoyés, la tâche par lot est immédiatement terminée et marquée comme échouée.
Si la méthode start renvoie un QueryLocator, le paramètre de portée facultatif de Database.executeBatch peut avoir une valeur maximale de 2000. Si vous définissez une valeur plus importante, Salesforce segmente les enregistrements renvoyés par QueryLocator en lots plus petits limités à 2000 enregistrements. Si la méthode start renvoie un itérable, la valeur du paramètre de portée n'a pas de limite maximale. Si vous utilisez une valeur très élevée, vous risquez toutefois d'atteindre d'autres limites.
Si aucune taille n'est spécifiée avec le paramètre facultatif scope de Database.executeBatch, Salesforce segmente les enregistrements renvoyés par la méthode start en lots de 200, puis passe chaque lot à la méthode execute. Les limitations du gouverneur Apex sont réinitialisés à chaque exécution de la méthode execute.
Chaque méthode start, execute et finish peut mettre en oeuvre jusqu'à 10 appels.
Les exécutions par lot sont limitées à 10 appels par exécution de méthode.
Le nombre maximal d'exécutions par lot est de 250 000 par 24 heures.
Une seule méthode start d'une tâche Apex par lot peut être exécutée à la fois dans une organisation. Les tâches par lot qui n'ont pas encore commencé restent dans la file d'attente jusqu'à leur démarrage. Notez que cette limite n'entraîne aucun échec de tâche par lot, et les méthodes execute des tâches Apex par lot continuent de s'exécuter en parallèle si plusieurs taches simultanées sont en cours.