Performance Testing for High-Concurrency User Traffic

Find the user count where your site stops scaling

Most capacity questions are one question: at how many concurrent users does response time stop being flat? This template answers it with a stepped ramp to 2,000 users held for ten minutes, so the results page can show response time against user level and mark the step where the curve bends. It is the general-purpose capacity test; the other templates are variations of it for a specific stack or failure mode.

Configuration

Run this templateOpens the cloud test form with these values filled in. Free plan runs it at the free user limit; sign in or create a free account first.

The button prefills users, duration and ramp-up. Add the URLs and a think time, then start; on the free plan the user count is capped at the free limit, so run it there first to check the setup and rerun at full size on a paid plan.

What to read in the results

• Response time by user level. The Overview tab charts mean and p95 against the number of active users. Flat then climbing is normal; the step where it starts climbing is your ceiling, and the capacity panel names that step.
• Throughput plateau. Requests per second should rise in step with users. When users keep rising and requests per second stop, the server is saturated: every extra user only adds queueing.
• Errors by status code. 5xx and timeouts at the top of the ramp are capacity; 429s are a rate limiter; 4xx from the start is a setup problem, fix it before reading anything else.

Pass/fail thresholds for this template

Save them on the test once and every run gets a PASS or FAIL; the Trend tab then shows whether a release moved the ceiling.

The same scenario as a k6 script

The same shape as a k6 script: ten stages, each adding 200 users, then a ten-minute hold. Upload it to a k6 cloud test if you prefer scripts to the form.

import http from 'k6/http';
import { check, sleep } from 'k6';

const steps = [];
for (let i = 1; i <= 10; i++) steps.push({ duration: '30s', target: i * 200 });
steps.push({ duration: '10m', target: 2000 });

export const options = {
  stages: steps,
  thresholds: { http_req_duration: ['p(95)<1000'], http_req_failed: ['rate<0.01'] },
};

const pages = ['/', '/category/shoes', '/product/123', '/search?q=boots', '/api/cart'];

export default function () {
  const res = http.get('https://www.example.com' + pages[Math.floor(Math.random() * pages.length)]);
  check(res, { 'status 200': (r) => r.status === 200 });
  sleep(2 + Math.random() * 3);
}

When to run it

• Before any event that doubles traffic: a sale, a launch, a campaign, a press mention.
• After scaling changes new instance sizes, a new database tier, a cache in front of the app.
• Monthly on a schedule so the ceiling is a number you track, not a surprise.

FAQ on high-concurrency load testing

How do I choose the number of users?

Start from your busiest hour in analytics, convert to concurrent users (sessions per hour times average session length in hours), and set the test two to five times higher. The goal is to pass the ceiling.

Should I use requests per second instead of users?

Users with think time model people; a fixed request rate models an API client. This template models people. For an API, see the REST API stress template.

The results show the free plan’s user count, not 2,000.

The free plan caps virtual users. The prefill is clamped to your plan; upgrade or lower the target to compare like with like.

What does "the curve bends" look like?

Mean and p95 stay roughly flat across the first few levels, then rise with every additional level while throughput stops rising. The capacity panel on the results page marks that level automatically.