Please note that Salesforce Support can’t design or interpret customer scale test results. Support’s role is to monitor test activity and make sure that there are no issues with Salesforce services.
You can request an LAP (Limit, Activation, Permissions) process for testing at 120 RPS (Requests Per Second) or below. This is called a performance test.
Or, you can use Scale Test for testing above 120 RPS.
If you’re unfamiliar with scale testing, ask your account executive to engage our Success teams. They can help make sure that your tests are appropriately designed and conducted, and that the results accurately predict production scalability.
To request a Performance Test for 120 RPS or below, contact Support through the Salesforce Help site. Submit an LAP request for approval at least one week in advance of the testing date. Requests without notice are denied unless they’re categorized as urgent.
Make a test plan and include this information in the case description.
A copy of the test plan that you created in Scale Test (image shown for example only).
The time and date when the test starts.
The time and date when the test ends.
The Organization ID for the sandbox where the test occurs. Scale tests can be conducted only in a sandbox.
The contact information of the person conducting the test, including name, phone number, and email.
The business case or scenario to test, for example, holiday shopping event or new website launch.
The business justification for testing.
Changes and customizations to your production Salesforce implementation can impact performance. For this reason, it’s wise to run sandbox scale tests above 120 RPS on a production-like scale with enhanced infrastructure and capacity provided by Scale Test.
To get started, read Measure Performance for Your Salesforce Org, then generate your test plan and schedule a testing window with Scale Test.
To get access, contact your customer success representative or account executive. From Setup, in the Quick Find box, enter Scale, and then click Scale Test.
Scale Test is a paid add-on available for full sandbox users, designed to validate a Salesforce implementation's ability to handle production-level traffic. The process involves using metrics like Requests Per Second (RPS), Experienced Page Time (EPT), and server-side traffic to help you plan tests. Schedule a test slot and run the test at production peak load to compare data with previous tests. Use Scale Center for further insights and optimization.
Before testing, make sure that you understand Salesforce Developer Limits. If you exceed these limits, a throttle can be applied to your system. To help reduce the risk of throttling, Scale Test provides a ramp schedule for your test plan. Learn more about throttles.
Follow these steps to create your test plan:
Identify the scenarios that you plan to test and their success criteria.
Visit the Test Plan Creation page in Scale Test. This allows you to build a trial run based on the use cases that you observe in your production peak hour.
NOTE: Greenfield customers (implementing a first-time Salesforce instance) and customers about to go live should design their own test plans and don’t need to use the Test Plan Creation feature. They can use an RPS estimator to understand their scale and proceed with booking the actual test.
In a sandbox, run a baseline test for each scenario with 50 users for a minimum of 30 minutes. Tests with 50 users or fewer usually don’t require case approvals.
Use Trial Accuracy Checker to create a sandbox trial run by simulating the production peak-hour traffic.
To calculate the expected peak load for inbound requests and API calls, use the RPS Estimator tool in Scale Test.
You can request an LAP (Limit, Activation, Permissions) process for testing at 120 RPS or below. This is called a performance test.
Or, you can use Scale Test for testing above 120 RPS (Requests Per Second).
Not necessarily. The support team doesn’t:
Validate testing methodology.
Debug testing scripts for errors.
Confirm that the scripts accurately test and reflect real-world scenarios of expected behavior in production.
Support makes these recommendations for all test execution frameworks:
No hard-coded locations to external files in scripts.
Parameterized URLs, usernames, and passwords.
Disabled single sign-on and no IP range restrictions for user profiles
Five-second think time between requests.
Tests must be preapproved. Unapproved testing is subject to throttling or blocking. Preapproval of your testing regimen allows Salesforce Support to:
Ensure scheduling of Site Reliability (SR) and Customer Centric Engineering (CCE) team resources.
Make SR and CCE aware of any ongoing testing and communication details in case it’s necessary to throttle or block testing.
Note: If your testing activity degrades performance on the instance, even approved testing can be throttled or blocked. If your test is throttled, a support agent will reach out to you to remediate.
Preview scripts and deny those that can degrade performance on the instance.
Book Scale Test days as an option when Requests Per Seconds (RPS) are higher than 80-100.
Proactive Monitoring (PRoM) works alongside Scale Center as part of Salesforce's scalability suite. Scale Center provides performance monitoring and analysis capabilities, while ProM focuses on alerting and proactive issue detection.
In Scale Center, you can also use on-demand Lightning Experience Insights to identify slow pages, components, and actions.
Salesforce Support doesn’t provide overall metrics or server logs for the testing period. If you have a specific request for information, for example:
The running or CPU time for a particular process at a given time for a particular user.
Details to help troubleshoot an error that occurred during the test.
Under these circumstances, Support can sometimes extract and provide a limited set of server log data to answer such questions. Work with your support agent to gather this information.
Salesforce Help: Scale Test Overview
Trailhead: Scale Test Quick Look
Trailhead: Peak Load Tests with Scale Test
000387059

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.