Governor Limits in Salesforce are the runtime limits enforced by the Apex runtime engine to write scalable and efficient code. Every programming environment imposes its own sets of constructs, features, and constraints. All programs, services, and applications running on the platform run in a multi-tenant environment where their resources like memory, network, database connections are being shared with every other program on the platform. Therefore it’s very important that the platform prevents rouge, runaway applications from saturating system resources.
- Force.com implements a number of governors and limits to ensure that all applications “play nicely” with each other.
- They often analyze our code to ensure that we are using best practices and system resources efficiently.
When developing custom applications, you have to actively take into consideration Apex Governor Limits. The Apex runtime engine strictly enforces limits and issues a runtime exception if, for instance, a script exceeds a limit. Governor limits in Salesforce differ based upon the entry point of your code. For instance, when a Trigger is called from a Visualforce Controller the Apex runtime this limit on a case by case basis”
The Apex limits, or governors, track and enforce the statistics outlined in the following tables and sections.
- Per-Transaction Apex Limits
- Per-Transaction Certified Managed Package Limits
- Force.com Platform Apex Limits
- Static Apex Limits
- Size-Specific Apex Limits
- Miscellaneous Apex Limits
- Email Limits
- Push Notification Limits
Per-Transaction Apex Limits
These limits count for each Apex transaction. For Batch Apex, these limits are reset for each execution of a batch of records in the execute method.
This table lists limits for synchronous Apex and asynchronous Apex (Batch Apex and future methods) when they’re different. Otherwise, this table lists only one limit that applies to both synchronous and asynchronous Apex.
How to Avoid SOQL Query Limit
You can issue only 100 queries per transaction, that is, when your code will issue more than 100 SOQL queries then it will throw an error.
- Avoid SOQL Queries or DML statements inside FOR Loops.
- Using Collections, Streamlining Queries, and Efficient For Loops.
- Merge if the trigger is redundant.
- Use @future appropriately.
- One trigger per object.
- Write logic less trigger
- Use context-Specific Handler Methods
- Smaller Batch Sizes
- Use Limit Apex methods
- Avoid hardcoding IDs
- Write test methods to verify large datasets
Some Important Tips:-
- Test Classes:
Initially, we had to create test data in every test method, because every test method is considered a different transaction with its own governor limits. But Salesforce has introduced @TestSetUp annotation for test class method. You can write a method in the test class, with @TestSetUp annotation applied, and create all your common test data in this method.
Few key points about TestSetUp methods:
- A method marked with @TestSetUp annotation executes before any testMethod.
- Data created in this method doesn’t need to be created again and again, and it is by default available for all test methods.
- There can be only one setup method per test class.
- Test setup methods are supported only with the default data isolation mode for a test class. If the test class or a test method has access to organization data by using the @isTest(SeeAllData=true) annotation, test setup methods aren’t supported in this class.
- Test setup methods are available for 24.0 or later versions only.
- Every test method will get an unchanged version of the test data created in setup method, doesn’t matter if any other test method has modified the data. We will show this in testMethod2 of below example.
- Do governor limits apply to sandbox instances?
Governor limits do apply to all Salesforce instances (trial, developer, production or sandbox environments). However, code coverage and successful execution of test classes are only enforced when deploying to a production environment.
- What are few limitations (points to remember) of Savepoint or Transaction Control in Apex?
Each savepoint you set counts against the governor limit for DML statements.
Static variables are not reverted during a rollback. If you try to run the trigger again, the static variables retain the values from the first run.
Each rollback counts against the governor limit for DML statements. You will receive a Runtime error if you try to rollback the database additional times.
The ID on an sObject inserted after setting a savepoint is not cleared after a rollback.
- Detecting governor limits through apex
First, the exception is thrown by hitting a limit, System.LimitException is uncatchable and means that your script will be killed, even if it happens inside a try/catch block. There is a class, Limits, that contains a number of static methods that allow you to check your governor limit consumption,
With that said, your example of @future calls per day is one of the limits that simultaneously is and isn’t a governor limit as I believe it throws a System.AsyncException instead which is not catchable, and kills your script as a Limit Exception would.