In our previous blog post we had discussed about Order of Execution of Batch Apex Job. In these blog post we discuss about Governor Limits & Limitations in Apex
Contents
- 1 Governor Limits & Limitations in Apex
- 2 What Are Governor Limits?
- 3 Types of Governor Limits in Salesforce Apex
- 4 CPU Time Limit
- 5 SOQL Query Limits
- 6 DML Statement Limits
- 7 Heap Size Limit
- 8 Callout Limits
- 9 Concurrent Apex Limitations
- 10 Total Number of Records Retrieved by SOQL Queries
- 11 Too Many Future Calls Exception
- 12 Best Practices for Working with Governor Limits
- 13 Using @future and Batch Apex to Handle Limits
- 14 Governor Limit Exceptions
- 15 Conclusion
- 16 FAQs
Governor Limits & Limitations in Apex
What Are Governor Limits?
Governor limits are a set of rules imposed by Salesforce to maintain the performance and multi-tenancy of the platform. Since Salesforce operates in a shared environment where multiple users access the same infrastructure, these limits prevent individual scripts or transactions from monopolizing system resources.
The primary purpose of governor limits is to ensure that no single user or organization negatively impacts the overall system performance. It forces developers to write optimized, efficient code by limiting the resources that any single transaction can consume.
Types of Governor Limits in Salesforce Apex
There are several types of governor limits in Salesforce, each with specific implications on how developers can execute transactions. The most important types include:
- Per-Transaction Limits
These limits apply to each Apex transaction, restricting the number of resources that can be consumed during a single transaction. - Org-Wide Limits
These limits apply across the entire Salesforce organization and track the usage of shared resources like API calls or platform events. - Static Apex Limits
Certain limits are static and cannot be exceeded, regardless of the context. These apply to specific features like heap size, DML rows, and SOQL queries.
CPU Time Limit
Every Apex transaction is allotted a maximum CPU time. This ensures that individual processes don’t overconsume processing power, leading to slower performance for other users on the shared platform. CPU time is measured in milliseconds, and the limit is currently 10,000 ms (10 seconds) for synchronous operations.
To manage CPU time effectively:
- Optimize your code for efficiency.
- Minimize unnecessary loops and operations.
- Use batch processing when handling large volumes of data.
SOQL Query Limits
Salesforce limits the number of SOQL (Salesforce Object Query Language) queries a transaction can perform. The limit is 100 SOQL queries per synchronous transaction and 200 for asynchronous transactions. If exceeded, the system throws a Too Many SOQL Queries exception.
To avoid exceeding the limit:
- Avoid using SOQL inside loops.
- Optimize queries by filtering and selecting only required fields.
- Use query plan tools to analyze and optimize complex queries.
DML Statement Limits
DML (Data Manipulation Language) operations allow for inserting, updating, or deleting records in Salesforce. There is a governor limit on the number of DML statements that can be executed in a single transaction—currently 150 DML statements for synchronous operations.
Best practices include:
- Bulkify your code to reduce the number of DML statements.
- Perform DML operations on lists of objects instead of individual records.
Heap Size Limit
Heap size is the amount of memory a transaction consumes. Salesforce enforces limits on heap size, which is 6 MB for synchronous transactions and 12 MB for asynchronous transactions.
Strategies to manage heap size:
- Avoid storing large amounts of data in memory.
- Use pagination when dealing with large datasets.
- Release memory by removing unused variables and objects.
Callout Limits
Salesforce limits the number of callouts (external service requests) that can be made in a single transaction. The limit is 100 callouts per transaction. Exceeding this limit will result in a Too Many Callouts exception.
To manage callouts:
- Consolidate multiple service calls into a single call when possible.
- Ensure that callouts are absolutely necessary and efficient.
Concurrent Apex Limitations
Salesforce limits the number of concurrent long-running requests. If multiple users or processes attempt to execute long-running operations simultaneously, only a limited number will be processed concurrently.
To avoid concurrent limits:
- Use asynchronous processing like @future methods or Batch Apex.
- Design workflows that avoid simultaneous execution of long-running operations.
Total Number of Records Retrieved by SOQL Queries
Salesforce limits the number of records that can be retrieved by SOQL queries in a single transaction to 50,000. This ensures that large datasets do not overwhelm the system.
Workarounds include:
- Breaking large queries into smaller, more manageable chunks.
- Using Batch Apex to process large data sets incrementally.
Too Many Future Calls Exception
This exception occurs when more than 50 @future calls are made in a single transaction. To prevent this:
- Reduce the use of @future calls.
- Consolidate logic that can be executed in one future call rather than many.
Best Practices for Working with Governor Limits
Working within governor limits requires understanding and optimizing code. Some key best practices include:
- Bulkify operations by processing records in bulk.
- Use SOQL for loops and avoid using SOQL inside loops.
- Handle exceptions gracefully to avoid disrupting user experience.
Using @future and Batch Apex to Handle Limits
When working with large datasets or long-running processes, Batch Apex or @future methods are lifesavers. They allow you to process records in batches or asynchronously, staying within governor limits.
- Batch Apex splits large operations into smaller, more manageable pieces.
- @future allows you to run processes asynchronously to avoid hitting synchronous limits.
Governor Limit Exceptions
Common exceptions related to governor limits include:
- System.LimitException: Too Many SOQL Queries
- System.LimitException: Too Many DML Statements
- System.LimitException: CPU Time Limit Exceeded
Handling these exceptions in your code ensures that users do not experience errors and that processes run smoothly.
Conclusion
Governor limits in Salesforce Apex are essential for maintaining platform performance and fairness in a multi-tenant environment. By adhering to these limits and following best practices, developers can write efficient, scalable code that runs smoothly on the Salesforce platform.
We Want to more About Governor Limits & Limitations in Apex Click Here
FAQs
Why are governor limits necessary in Salesforce?
Governor limits ensure that resources are shared fairly among all users on the platform, maintaining performance and preventing any single transaction from consuming excessive resources.
What happens when a governor limit is exceeded?
If a governor limit is exceeded, Salesforce throws a LimitException, and the transaction fails without committing any changes.
How can I check governor limits in Apex?
You can check governor limits in Apex by using the Limits class (e.g., Limits.getQueries()
to check SOQL query usage).
Can governor limits be increased?
No, governor limits are fixed and cannot be increased. However, you can optimize your code to work within these limits.
What are some best practices to stay within limits?
Bulkify your operations, avoid SOQL in loops, and use asynchronous processing methods like Batch Apex and @future.
In our next blog post we will discuss about Apex Scheduler in Salesforce
2 thoughts on “Governor Limits & Limitations in Apex”