Please do continue to like, share and subscribe sfdconestop Youtube
channel, if you find the Salesforce tutorials(100+ Video's) to be
informative!!
▶️Subscribe: https://www.youtube.com/c/sfdconestop
👉 https://sfdconestop.blogspot.com/
👀 Follow us on Linkedin : https://www.linkedin.com/company/sfdconestop
▶️Subscribe: https://www.youtube.com/c/sfdconestop
👉 https://sfdconestop.blogspot.com/
👀 Follow us on Linkedin : https://www.linkedin.com/company/sfdconestop
This is one of the Governor limit you may hit if you do not follow the best practices during implementation/code development. Below is the limit where for most of the orgs the limit is 10 which means you cannot have 10 synchronous transactions running concurrently for more than 5 second as for 11th request you hit the governor limit error as below -
Governor limit:
Number of synchronous concurrent requests for long-running requests that last longer than 5 seconds for each organization.*
Error:
"Unable to Process Request. Concurrent requests limit exceeded.
To protect all customers from excessive usage and Denial of Service attacks, we limit the number of long-running requests that are processed at the same time by an organization. Your request has been denied because this limit has been exceeded by your organization. Please try your request again later."
https://help.salesforce.com/articleView?id=admin_web_limits.htm&type=5
What Counts Against the Limit
A single synchronous Apex request could include Apex code, SOQL, callouts, and triggers. You might need to tune these and other common components because the duration of their transactions counts toward the request limit.
How to Design to Avoid the Limit
Take the concurrent request limit into consideration as you design your application around your business processes. Does the business process need to be synchronous? Is batch processing possible? Can you use the Streaming API?
Web Services
The most common causes of limit errors are synchronous Web service callouts. When one of your application’s users submits an order, that business process depends upon one or more external Web services, which must finish running for your application to actually create the order. If these external Web services cannot scale to your expected volumes, consider alternative solutions, such as using a callback instead of waiting for the callouts to complete.
To use a callback, just continue to make the synchronous callout. The following steps complete automatically after that.
The external Web service immediately returns an acknowledgement, saying that it received your request.
After the external Web service processing completes, it calls an Apex Web service to update the appropriate data.
The Streaming API publishes that updated data.
SOQL
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.
Refer to the Force.com Query Optimizer webinar for more information.
Data Skew
Data skew can also contribute to concurrent request limit errors. Consider the following scenario. You have a parent object with 10,000 or more child objects. Ordinarily, when you insert or change an owner of a child object, the Force.com platform automatically locks the parent for a certain amount of time. However, because you have data skew, the platform holds this lock even longer while determining the appropriate record access. The wait time for your lock is included in your total request time, and it causes your request to run for more than 5 seconds.
To avoid data skew so that you can also avoid ending up in this situation, read Reducing Lock Contention by Avoiding Data Skew.
Visualforce
With the ActionPoller component, you can poll by calling an Apex class. Unfortunately, you can’t dynamically change the polling interval or condition. This can result in a large number of unneeded requests. 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, not polling, to subscribe to near real-time notifications of changes to data.
The <Apex:ActionFunction> component provides support for invoking controller action methods directly from JavaScript code using an AJAX request. JavaScript remoting extends this capability and allows you to create pages with complex, dynamic behavior that isn’t possible with the standard Visualforce AJAX components. However, from an Apex perspective, both of these components are still synchronous requests that are similar to standard Visualforce requests, and they count toward your concurrency limit.
Summary
The concurrent request limit attempts to ensure a positive user experience by limiting the number of synchronous Apex requests running for more than 5 seconds. Once the limit is reached, new synchronous Apex requests are denied. This behavior can be disruptive to your work. Therefore, it is easier to avoid this limit when designing new applications than it is when tuning live applications. You can accomplish this goal by ensuring that your users’ workflows do not include synchronous requests that take longer than 5 seconds.
Some useful tips:
Convert synchronous processes to asynchronous processes. Batch Apex might be a viable alternative. Limit synchronous Web service callouts.
Use the Streaming API instead of polling
Tune SOQL and DML operations. Make sure that your queries are selective. Limit the number of records in your list views. Avoid data skew.
Governor limit:
Number of synchronous concurrent requests for long-running requests that last longer than 5 seconds for each organization.*
Error:
"Unable to Process Request. Concurrent requests limit exceeded.
To protect all customers from excessive usage and Denial of Service attacks, we limit the number of long-running requests that are processed at the same time by an organization. Your request has been denied because this limit has been exceeded by your organization. Please try your request again later."
https://help.salesforce.com/articleView?id=admin_web_limits.htm&type=5
What Counts Against the Limit
A single synchronous Apex request could include Apex code, SOQL, callouts, and triggers. You might need to tune these and other common components because the duration of their transactions counts toward the request limit.
Apex
|
Classes/controllers, triggers
|
SOQL
| |
Web Services
|
External and Apex Web Services
|
Visualforce
|
ActionPoller, Ajax/ActionFunctions, JavaScript Remoting
|
API
|
Calls to an Apex Class
|
How to Design to Avoid the Limit
Take the concurrent request limit into consideration as you design your application around your business processes. Does the business process need to be synchronous? Is batch processing possible? Can you use the Streaming API?
Web Services
The most common causes of limit errors are synchronous Web service callouts. When one of your application’s users submits an order, that business process depends upon one or more external Web services, which must finish running for your application to actually create the order. If these external Web services cannot scale to your expected volumes, consider alternative solutions, such as using a callback instead of waiting for the callouts to complete.
To use a callback, just continue to make the synchronous callout. The following steps complete automatically after that.
The external Web service immediately returns an acknowledgement, saying that it received your request.
After the external Web service processing completes, it calls an Apex Web service to update the appropriate data.
The Streaming API publishes that updated data.
SOQL
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.
Refer to the Force.com Query Optimizer webinar for more information.
Data Skew
Data skew can also contribute to concurrent request limit errors. Consider the following scenario. You have a parent object with 10,000 or more child objects. Ordinarily, when you insert or change an owner of a child object, the Force.com platform automatically locks the parent for a certain amount of time. However, because you have data skew, the platform holds this lock even longer while determining the appropriate record access. The wait time for your lock is included in your total request time, and it causes your request to run for more than 5 seconds.
To avoid data skew so that you can also avoid ending up in this situation, read Reducing Lock Contention by Avoiding Data Skew.
Visualforce
With the ActionPoller component, you can poll by calling an Apex class. Unfortunately, you can’t dynamically change the polling interval or condition. This can result in a large number of unneeded requests. 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, not polling, to subscribe to near real-time notifications of changes to data.
The <Apex:ActionFunction> component provides support for invoking controller action methods directly from JavaScript code using an AJAX request. JavaScript remoting extends this capability and allows you to create pages with complex, dynamic behavior that isn’t possible with the standard Visualforce AJAX components. However, from an Apex perspective, both of these components are still synchronous requests that are similar to standard Visualforce requests, and they count toward your concurrency limit.
Summary
The concurrent request limit attempts to ensure a positive user experience by limiting the number of synchronous Apex requests running for more than 5 seconds. Once the limit is reached, new synchronous Apex requests are denied. This behavior can be disruptive to your work. Therefore, it is easier to avoid this limit when designing new applications than it is when tuning live applications. You can accomplish this goal by ensuring that your users’ workflows do not include synchronous requests that take longer than 5 seconds.
Some useful tips:
Convert synchronous processes to asynchronous processes. Batch Apex might be a viable alternative. Limit synchronous Web service callouts.
Use the Streaming API instead of polling
Tune SOQL and DML operations. Make sure that your queries are selective. Limit the number of records in your list views. Avoid data skew.