Load test a test

Run one test many times at once and read the latency distribution.

In short

A load test runs one test, or ad-hoc SQL, many times at once. It keeps the timing distribution: p50 to p99, executions per second and a histogram, plus how many runs failed, deadlocked or timed out. Load testing is included in Pro, Business and Enterprise.

Before you start

• Who: running a load test needs Edit on the project.
• Plan: load testing is included in Pro, Business and Enterprise; one load test counts once toward an hourly allowance (Plan & usage shows it).
• First: a saved test or the SQL, and an environment you may run in. Start small.

Run a load test

1. Open the "Load testing" tab and choose an environment.
2. Choose a "Saved test", or switch to "Ad-hoc SQL" and paste a statement.
3. Set "Concurrency" - how many run at once (1 to 50, default 5).
4. Set "Executions" - the total (1 to 5,000, default 50) - and a Timeout per execution (1 to 300 seconds, default 30).
5. Press "Run load test" and wait for the Results card and the Latency histogram.

Good to know

• Every execution passes the same safety check as a single run, and every one rolls back, even for a test that asks for Commit.
• Only one row per result set is captured, so use a load test for timing, not for checking data. The individual executions are discarded.
• One load test counts once toward your hourly allowance: 20 on Pro and Business, 100 on Enterprise, none on Free. Its executions do not count toward your run limits.
• When the server resolves a deadlock it picks a victim, which can be someone else's transaction. Avoid high concurrency on a shared QA database during working hours.

This is real traffic 50 concurrent executions of a heavy query slow the database for everyone, and open transactions hold locks. Start with Concurrency 5 and Executions 50, on a database set aside for it. A Production load test is read-only, but its read load reaches paying customers - treat it as a change that needs approval.

Example: find a deadlock

Invoice creation sometimes fails at month end. You run Create invoice on QA at Concurrency 20 and Executions 500: 16 deadlocks, p95 410 ms. At Concurrency 5 there are none. The procedure locks two tables in a different order on two code paths. After the fix, Concurrency 20 shows zero deadlocks, and both results sit side by side in Recent load tests.

If something goes wrong

• The test stops at once with a reason: the first execution was refused by policy. Fix what the reason names.
• "A load test needs a saved test or SQL text."
• Load testing is not in your plan, or the hourly allowance is used up: the message says when more are available.

Related

• /help/sql-tester/safety-tiers-and-load-testing
• /help/api-testing/load-testing
• /help/settings/plan-limits