How to Simulate 100 Concurrent Users on Your API (No Code Required)

Most developers only test their APIs sequentially: send one request in Postman, check the 200 OK status code, and call it ready for production.

Then launch day arrives. Fifty users hit the checkout endpoint at the same moment, and the server crashes with `502 Bad Gateway` or `504 Gateway Timeout`.

Testing concurrency is non-negotiable before shipping any public feature. Traditionally, setting up a load test meant writing JavaScript files for k6, compiling Java threads in JMeter, or managing complex CLI setups.

Here is how to simulate 100 concurrent users directly in your browser in under two minutes without writing a single line of test code.

1. What Happens to Your Server at 100 Concurrent Users?

"Concurrent users" does not mean 100 people visiting your website throughout the day. It means 100 distinct requests executing in parallel in the exact same millisecond.

Here is what fails when an unoptimized backend receives 100 concurrent requests:

┌─────────────────────────────────────────────────────────────┐
│ 100 Concurrent Incoming Requests                            │
└──────────────────────────────┬──────────────────────────────┘
                               ▼
┌─────────────────────────────────────────────────────────────┐
│ Nginx / Reverse Proxy: worker_connections limit check       │
└─────────────────────────────┬───────────────────────────────┘
                               ▼
┌─────────────────────────────────────────────────────────────┐
│ Node.js / Python / Go: Event loop & thread pool saturation   │
└─────────────────────────────┬───────────────────────────────┘
                               ▼
┌─────────────────────────────────────────────────────────────┐
│ Database: Connection pool exhausted (e.g. max_connections=20)│
└─────────────────────────────┬───────────────────────────────┘
                               ▼
              💥 Result: 504 Gateway Timeout / Crash

1. Database Lock Contention: When multiple workers attempt to update the same record (such as deducting inventory or updating a user balance), transactions lock rows. Subsequent workers wait, creating a cascading backlog.

2. Reverse Proxy Starvation: Nginx or Apache runs out of worker connections, dropping incoming TCP connections before they reach your app.

3. Memory Spikes: Allocating memory buffers for 100 concurrent payloads simultaneously can trigger out-of-memory (OOM) kills on small cloud VPS instances (e.g., 1GB–2GB RAM).

2. Step-by-Step Guide: Running a 100-User Load Test

Using API Test Lab's Free & Pro Tiers, you can spin up 100 concurrent workers without installing any desktop software or CLI packages.

Step 1: Define Your Target Endpoint

Open the API Test Lab Dashboard and enter your endpoint details:

• Method: `POST`
• URL: `https://api.yourdomain.com/v1/checkout`
• Headers:

- `Content-Type: application/json`

- `Authorization: Bearer <test-token>`

Step 2: Configure Concurrency Parameters

In the Load Testing tab, configure your run:

• Worker Capacity: `100 workers`
• Ramp-Up Duration: `60 seconds` (Gradually introduces workers from 1 to 100 to prevent sudden false-positive network spikes).
• Test Duration: `5 minutes`

Step 3: Execute and Watch Real-Time Telemetry

Hit Start Load Test. The engine spawns virtual workers and streams real-time telemetry:

• Requests Per Second (RPS)
• Real-Time Error Rate (4xx / 5xx)
• Percentile Distributions (p50, p95, p99)

Sample Load Test Telemetry Output:

Workers: 100 concurrent       Duration: 00:05:00       Total Requests: 14,820
Success Rate: 99.4%           p50 Latency: 142ms       p95 Latency: 410ms
p99 Latency: 890ms            Status Breakdown: 200 OK: 14,731 | 429 Throttled: 89

3. Interpreting the Results: What to Look For

The "Knee Point" (Saturation Threshold)

Watch the graph as concurrency ramps from 1 to 100. As long as throughput (RPS) rises linearly with workers, your server is handling the traffic.

When throughput plateaus and response latency starts spiking vertically, you have identified your application's maximum saturation point.

HTTP 429 Too Many Requests

If your load test returns 429 status codes, your rate-limiting middleware (e.g., `express-rate-limit` or Cloudflare) is working. Ensure that legitimate production traffic thresholds are tuned above normal surge volumes.

HTTP 502 Bad Gateway

A 502 indicates that your upstream application process (Node.js/Python) crashed or restarted under load, causing Nginx to return an error.

4. How to Optimize Your API for Concurrency

• Scale Database Pools: Ensure `poolSize` in your ORM (Prisma, Mongoose, TypeORM, SQLAlchemy) is aligned with your available database RAM and CPU cores.
• Add Redis Caching: Offload repetitive `GET` requests to in-memory caches.
• Keep Handlers Non-Blocking: Never run synchronous computations, CPU-heavy regexes, or large JSON parsing operations inside the main event loop.

Frequently Asked Questions

Is running a load test safe for my production database?

Always run heavy load tests against a dedicated staging environment with data that mirrors production. Running 100 concurrent workers against production can create dirty data and degrade actual user sessions.

How does API Test Lab generate 100 concurrent users without local software?

Load tests run on isolated cloud workers managed by API Test Lab. Your browser only displays the streaming telemetry, meaning your local machine's CPU and bandwidth never distort the test results.