Salesforce Governor Limits are restrictions that are placed on Apex code to prevent it from consuming too many resources and causing performance problems. These limits are in place to ensure that all Salesforce users have a fair and consistent experience.
There are a number of different Governor Limits, each of which limits a different aspect of Apex code. Some of the most common Governor Limits include:
Execution time limit
The execution time limit is the maximum amount of time that an Apex code can run before it is terminated by the Salesforce Governor. The default execution time limit is 10 seconds, but it can be increased up to 30 seconds.
The execution time limit is measured from the time the Apex code starts running until it finishes running. This includes the time spent executing statements, making calls to other Apex classes or to the Salesforce API, and waiting for database queries to return results.
If an Apex code exceeds the execution time limit, it will be terminated by the Salesforce Governor and an exception will be thrown. The exception message will indicate that the code exceeded the execution time limit.
There are a few things that can cause an Apex code to exceed the execution time limit. These include:
Writing inefficient code that takes a long time to execute.
Making a lot of calls to other Apex classes or to the Salesforce API.
Waiting for a long time for database queries to return results.
There are a few things that you can do to avoid exceeding the execution time limit. These include:
Writing efficient code that takes a reasonable amount of time to execute.
Using bulk API calls to execute multiple DML statements in a single transaction.
Using Apex Triggers sparingly.
Using SOQL queries efficiently.
Concurrent call limit
The concurrent call limit is the maximum number of concurrent calls that an Apex code can make to other Apex classes or to the Salesforce API. The default concurrent call limit is 20, but it can be increased up to 100.
A concurrent call is a call that is made to an Apex class or to the Salesforce API while another call is already in progress. For example, if an Apex code makes a call to another Apex class, and that Apex class makes a call to another Apex class, then there are two concurrent calls in progress.
The concurrent call limit is designed to prevent Apex code from making too many calls to other Apex classes or to the Salesforce API at the same time. This helps to prevent performance problems and ensure that all Salesforce users have a fair experience.
If an Apex code exceeds the concurrent call limit, it will be throttled by the Salesforce Governor. This means that the code will not be able to make any more calls until some of the existing calls have finished.
There are a few things that can cause an Apex code to exceed the concurrent call limit. These include:
Making a lot of calls to other Apex classes or to the Salesforce API.
Making recursive calls (calls that call themselves).
Using Apex Triggers that make a lot of calls.
There are a few things that you can do to avoid exceeding the concurrent call limit. These include:
Using bulk API calls to execute multiple DML statements in a single transaction.
Using Apex Triggers sparingly.
Using SOQL queries efficiently.
Database DML (Data Manipulation Language) statement limit
The database DML statement limit is the maximum number of database DML statements that an Apex code can execute in a single transaction. The default database DML statement limit is 100, but it can be increased up to 1000.
DML statements are statements that change the data in the Salesforce database. These include statements like insert, update, and delete.
The database DML statement limit is designed to prevent Apex code from making too many changes to the Salesforce database in a single transaction. This helps to prevent performance problems and ensure that all Salesforce users have a fair experience.
If an Apex code exceeds the database DML statement limit, it will be throttled by the Salesforce Governor. This means that the code will not be able to execute any more DML statements until some of the existing DML statements have finished.
There are a few things that can cause an Apex code to exceed the database DML statement limit. These include:
Making a lot of DML statements in a single transaction.
Using loops to execute DML statements multiple times.
Using Apex Triggers that make a lot of DML statements.
There are a few things that you can do to avoid exceeding the database DML statement limit. These include:
Using bulk API calls to execute multiple DML statements in a single transaction.
Using Apex Triggers sparingly.
Using SOQL queries to retrieve the data that you need before you make DML statements.
Remote call limit
The remote call limit is the maximum number of remote calls that an Apex code can make to other Salesforce organizations. The default remote call limit is 20, but it can be increased up to 100.
A remote call is a call that is made to an Apex class or to the Salesforce API in another Salesforce organization.
The remote call limit is designed to prevent Apex code from making too many calls to other Salesforce organizations. This helps to prevent performance problems and ensure that all Salesforce users have a fair experience.
If an Apex code exceeds the remote call limit, it will be throttled by the Salesforce Governor. This means that the code will not be able to make any more remote calls until some of the existing remote calls have finished.
There are a few things that can cause an Apex code to exceed the remote call limit. These include:
Making a lot of remote calls to other Salesforce organizations.
Using loops to make remote calls multiple times.
Using Apex Triggers that make a lot of remote calls.
There are a few things that you can do to avoid exceeding the remote call limit. These include:
Using the Salesforce Outbound Message API to make batched calls to other Salesforce organizations.
Using Apex Triggers sparingly.
Using SOQL queries to retrieve the data that you need before you make remote calls.
Governor Limits are important for ensuring that Salesforce users have a fair and consistent experience. However, they can also be a source of frustration for Apex developers, who may find their code being throttled or interrupted by the limits.
Do We Need Governor Limits?
Governor Limits are a set of restrictions that are placed on Apex code to prevent it from consuming too many resources and causing performance problems. These limits are in place to ensure that all Salesforce users have a fair and consistent experience.
There are a number of different Governor Limits, each of which limits a different aspect of Apex code. Some of the most common Governor Limits include:
Execution time limit: This limit restricts the amount of time that an Apex code can run. The default execution time limit is 10 seconds, but it can be increased up to 30 seconds.
Concurrent call limit: This limit restricts the number of concurrent calls that an Apex code can make to other Apex classes or to the Salesforce API. The default concurrent call limit is 20, but it can be increased up to 100.
Database DML (Data Manipulation Language) statement limit: This limit restricts the number of database DML statements that an Apex code can execute in a single transaction. The default database DML statement limit is 100, but it can be increased up to 1000.
Remote call limit: This limit restricts the number of remote calls that an Apex code can make to other Salesforce organizations. The default remote call limit is 20, but it can be increased up to 100.
Governor Limits are important for ensuring that Salesforce users have a fair and consistent experience. However, they can also be a source of frustration for Apex developers, who may find their code being throttled or interrupted by the limits.
The decision of whether or not to use Governor Limits is a trade-off between performance and flexibility. If you are concerned about performance, then you may want to keep the Governor Limits in place. However, if you need more flexibility in your Apex code, then you may want to consider disabling some of the Governor Limits.
Here are some of the pros and cons of using Governor Limits:
Pros:
Governor Limits can help to prevent performance problems. When too many Apex code runs at the same time, it can put a strain on the Salesforce system and cause performance problems. Governor Limits help to prevent this by throttling Apex code that is running too quickly.
Governor Limits can help to ensure that all Salesforce users have a fair experience. If some users are able to run their Apex code more quickly than others, this can give them an unfair advantage. Governor Limits help to prevent this by ensuring that all users are subject to the same limits.
Cons:
Governor Limits can be a source of frustration for Apex developers. When Apex code is throttled by Governor Limits, it can cause the code to run slower or even to fail. This can be frustrating for developers who are trying to write efficient and performant code.
Governor Limits can limit the flexibility of Apex code. Some Apex developers may need to write code that exceeds the Governor Limits in order to meet the needs of their users. In these cases, developers may need to find workarounds to the Governor Limits, which can be time-consuming and difficult.
Ultimately, the decision of whether or not to use Governor Limits is a trade-off between performance and flexibility. If you are concerned about performance, then you may want to keep the Governor Limits in place. However, if you need more flexibility in your Apex code, then you may want to consider disabling some of the Governor Limits.
Here are some tips for working with Governor Limits:
Understand the different Governor Limits. There are a number of different Governor Limits, each of which limits a different aspect of Apex code. It is important to understand these limits so that you can write code that does not exceed them.
Use bulk API calls. The bulk API can be used to execute multiple DML statements in a single transaction, which can help you to avoid hitting the database DML statement limit.
Use Apex Triggers sparingly. Apex Triggers are executed whenever a record is created, updated, or deleted. This can put a strain on the system, so it is important to use Apex Triggers sparingly.
Use SOQL queries efficiently. SOQL queries can be expensive, so it is important to use them efficiently. For example, you can use the LIMIT clause to limit the number of records that are returned by a query.
Optimize your code. By writing efficient code that takes a reasonable amount of time to execute, you can help to avoid hitting the execution time limit.
Disable Governor Limits. If you need to write code that exceeds the Governor Limits, you may need to disable some of the Governor Limits. However, this should only be done as a last resort, as it can increase the risk of performance problems.
How to Optimize Apex Code for Governor Limits
If you are working with Apex code that is being throttled by Governor Limits, there are a number of things that you can do to optimize your code for Governor Limits. Some of the most common optimization techniques include:
Break up your code into smaller methods: This will help to reduce the execution time of your code and make it less likely to hit the execution time limit. When you break your code into smaller methods, each method will be able to execute more quickly and will be less likely to be throttled by the Governor.
Use bulk API calls: The bulk API can be used to execute multiple DML statements in a single transaction, which can help you to avoid hitting the database DML statement limit. The bulk API is a set of tools that allow you to perform large-scale data operations in Salesforce. By using the bulk API, you can avoid making multiple individual DML statements, which can help you to avoid hitting the database DML statement limit.
Use Apex Triggers sparingly: Apex Triggers are executed whenever a record is created, updated, or deleted. This can put a strain on the system, so it is important to use Apex Triggers sparingly. If you can, try to avoid using Apex Triggers for tasks that can be performed by other means.
Use SOQL queries efficiently: SOQL queries can be expensive, so it is important to use them efficiently. For example, you can use the LIMIT clause to limit the number of records that are returned by a query. The LIMIT clause allows you to specify the maximum number of records that should be returned by a SOQL query. This can help you to avoid making unnecessary calls to the database.
Optimize your code: By writing efficient code that takes a reasonable amount of time to execute, you can help to avoid hitting the execution time limit. There are a number of things that you can do to optimize your code, such as using loops and conditional statements efficiently, and avoiding unnecessary computations.
By following these optimization techniques, you can help to ensure that your Apex code is not throttled by Governor Limits.
Conclusion
Governor Limits are an important part of Salesforce that help to ensure that all users have a fair and consistent experience. However, they can also be a source of frustration for Apex developers. By understanding how Governor Limits work and by optimizing your Apex code, you can help to avoid hitting the limits and ensure that your code performs as expected.