Monitoring Salesforce Governor Limits: Performance Testing Guide

Salesforce's Governor Limits are crucial to monitor during performance testing to ensure the stability and reliability of its multi-tenant environment. These limits are in place to prevent individual users or transactions from monopolising system resources and to ensure fair resource allocation. By monitoring these limits, developers can optimise their code, enhance application performance, and avoid issues that could impact the user experience. Salesforce provides tools and techniques to monitor and manage these limits, including debug logs, System.debug statements, and the Limits class in Apex. It's important to note that Governor Limits encompass various aspects of the platform, including CPU time, memory consumption, callouts, and database operations, and understanding these limits is essential for effective resource utilisation and application scalability.

CPU time limit

Salesforce has a CPU time limit of 10 seconds for synchronous transactions and 60 seconds for asynchronous processing. This means that Apex Code, declarative tools, or a combination of the two in a transaction must not exceed the 10-second limit. This limit is non-negotiable and cannot be increased by tweaking settings or buying more allocations from Salesforce. When the CPU time limit is reached, the execution is shut down immediately, and all database transactions are rolled back.

To monitor and resolve CPU time limit issues, you can follow these steps:

• Enable Live Debug Log: This will help you identify when the CPU Time Limit exception occurs. You can then analyse the debug log to find out which actions are consuming the most CPU time.
• Find Out What Consumes the Most CPU Time: Switch to the Analysis Perspective in the Developer Console to view a timeline of Apex, Workflow, and Database actions and how much time each of them consumes. You can also use third-party tools like SFDC Explorer for log visualisation.
• Optimise Trigger Logic: One common reason for hitting the CPU time limit is when the trigger logic enters multiple times unexpectedly. Ensure that your trigger logic is optimised and does not cause recursive entries.
• Optimise Apex Code: Review your Apex code to identify any performance bottlenecks, such as nested loops, which can slow down processing when dealing with a large volume of records.
• Review Managed Packages: If you are using managed packages, reach out to the vendor for assistance if you suspect that their code is consuming too much CPU time.

Additionally, Salesforce provides the OrgLimits class, which can be used to monitor governor limits and notify administrators when certain thresholds are reached. You can also use the Limits class to retrieve per-transaction information.

Database operations limit

Monitoring Salesforce governor limits in performance testing is crucial to ensure your code doesn't exceed the limits and break. Salesforce imposes Database Operations Limits to prevent any single client from monopolizing shared resources. These limits include restrictions on the number of SOQL queries, SOSL queries, DML statements, and records retrieved.

• Avoid SOQL queries and DML statements inside for loops. Instead, use collections to store data and perform DML operations on the collection, which only counts as one DML.
• Bulkify your code by processing multiple records at once instead of iterating over them individually.
• Use Aggregate SOQL queries to optimize database operations and reduce the number of queries.
• Monitor your code's performance using debug logs or custom exception frameworks to identify areas where you are close to hitting the limits.
• Follow best practices and design patterns, such as the Trigger framework, to avoid recursive issues and optimize your code.
• Use Platform Events or asynchronous processing like Queueables, Future methods, and Batches to handle large data volumes and scale your code effectively.

Heap size limit

The heap size limit is an important aspect of Salesforce governor limits, which are crucial for maintaining platform stability, performance, and fair usage. The Apex runtime maintains a heap that stores and manages objects and variables during code execution. The heap size is the amount of memory used by these variables and object instances, and Salesforce imposes a limit on this to prevent excessive memory consumption.

Salesforce provides a heap size limit of 6MB for synchronous transactions and 12MB for asynchronous transactions. If too much data is stored during processing, an error will occur, prompting an "Apex heap size too large" warning. This is a common issue encountered by developers.

To ensure that the heap limit is not exceeded, developers can follow several best practices. These include using efficient algorithms, leveraging built-in Apex libraries, avoiding temporary variables, shortening variable names and declarations, and removing unnecessary debug statements. By optimising code in this way, developers can significantly minimise heap size allocations and prevent errors.

Additionally, monitoring tools are available to track heap size usage and help developers identify potential limit violations. By regularly reviewing logs and performance metrics, developers can proactively address any issues and optimise their applications.

In summary, the heap size limit is an essential consideration in Salesforce performance testing. By understanding and staying within this limit, developers can build scalable and high-performing applications, ensuring a positive user experience.

Callout limit

The callout limit is one of the governor limits that can be monitored in Salesforce performance testing. Governor limits refer to the restrictions imposed by Salesforce on the amount of specific resources that can be used by a single Apex transaction or trigger to prevent resource abuse and ensure optimal performance.

The callout limit specifically restricts the number of callouts that can be made from an Apex transaction. A callout is when an Apex code initiates a request to an external service or system, such as sending an HTTP request to an external API. Callouts are resource-intensive and can impact the performance of Salesforce, so it is important to monitor and manage them effectively.

To monitor the callout limit, you can utilise the Limits class in Apex, which provides information about the current usage of various governor limits, including the number of callouts made. By accessing this class, you can retrieve the number of callouts that have been made so far in the transaction and compare it to the limit to determine if you are approaching the threshold.

Apex

Integer callouts = Limits.getCallouts();

System.debug('Number of callouts: ' + callouts);

If (callouts > 50) {

System.debug('Approaching callout limit. Limit is ' + Limits.getLimitCallouts());

}

In this code, `Limits.getCallouts`() returns the number of callouts made so far in the transaction. By comparing this value to a threshold (in this case, 50), you can determine if you are approaching the limit. Additionally, `Limits.getLimitCallouts`() returns the maximum allowed number of callouts, so you can display this value in your debug message to know exactly what the limit is.

It is important to note that the callout limit is subject to change and may vary depending on your Salesforce edition and other factors. Therefore, it is recommended to regularly review the official Salesforce documentation and release notes to stay updated on any changes to the callout limit and other governor limits.

By actively monitoring the callout limit and other governor limits, you can optimise your Apex code and avoid performance issues related to excessive resource usage. This helps ensure that your Salesforce applications run efficiently and maintain a positive user experience.

Concurrent request limit

The concurrent request limit is one of the governor limits that customers frequently reach. This limit is in place to protect the user experience and ensure that system resources are available to all customers. Once a synchronous Apex request runs longer than 5 seconds, it begins counting against this limit. Each organisation is allowed 10 concurrent long-running requests.

If the limit is reached, any new synchronous Apex request will result in a runtime exception. This behaviour occurs until the organisation's requests are below the limit.

The following count against the limit:

• Classes/controllers, triggers
• External and Apex Web Services
• ActionPoller, Ajax/ActionFunctions, JavaScript Remoting
• Calls to an Apex Class

To avoid hitting the concurrent request limit, consider the following:

• Does the business process need to be synchronous? Is batch processing possible? Can you use the Streaming API?
• The most common causes of limit errors are synchronous Web service callouts. If your application depends on one or more external Web services, consider using a callback instead of waiting for the callouts to complete.
• The performance of your queries and DML operations is another big contributor to long-running requests. As your data grows, inefficient SOQL affects Visualforce pages, detail pages, list views and reports. If you’re querying for large amounts of data, you’ll incur additional processing time both when querying and rendering the data.
• Data skew can also contribute to concurrent request limit errors. If you have a parent object with 10,000 or more child objects, the platform will hold the lock even longer while determining the appropriate record access. To avoid this, read 'Reducing Lock Contention by Avoiding Data Skew'.
• With the ActionPoller component, you can poll by calling an Apex class. If the polling operation is expensive and takes longer than 5 seconds, you’ll quickly hit the limit. For more scalable requests, use the Streaming API instead of polling to subscribe to near real-time notifications of changes to data.
• The component allows you to create pages with complex, dynamic behaviour. However, both this and JavaScript remoting are still synchronous requests that count toward your concurrency limit.

Salesforce Org Limits

Salesforce imposes a variety of limits to ensure fair use of its resources. These include:

• API Limits
• Salesforce Mass Email Limits
• Apex Limits
• Governor Limits
• Salesforce DML Limits
• Lightning Component Limits
• Report and Dashboard Limits
• Streaming API Limits
• Custom Metadata Limits
• Workflow Limits
• SOQL and SOSL Limits

Frequently asked questions