Knowledgebase

Load testing simulates real traffic against your site before a genuine spike occurs (a sale, launch, or marketing campaign), revealing bottlenecks while you still have time to fix them.

Why Load Test

• Discover your server's actual breaking point before real users find it for you
• Validate that recent performance optimizations actually helped
• Build confidence ahead of a known high-traffic event

Important: Only Test Servers You Own

Load testing infrastructure you don't own or explicitly have permission to test is inappropriate and can constitute a denial-of-service attack — only run these tools against your own servers or with explicit written authorization.

Tool 1 — Apache Bench (ab): Simple, Quick Tests

sudo apt install apache2-utils -y
ab -n 1000 -c 50 https://yourdomain.com/

-n 1000 sends 1000 total requests, -c 50 with 50 concurrent connections.

Interpreting Apache Bench Results

Requests per second:    142.35 [#/sec]
Time per request:       351.234 [ms]
Failed requests:        0

Watch specifically for a rising Failed requests count as you increase concurrency — that's your server's actual breaking point.

Tool 2 — wrk: More Advanced, Configurable Load Testing

sudo apt install wrk -y
wrk -t4 -c100 -d30s https://yourdomain.com/

-t4 uses 4 threads, -c100 maintains 100 open connections, -d30s runs for 30 seconds.

Tool 3 — k6: Scriptable, Realistic Load Testing

sudo apt install k6 -y

nano test.js

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

export const options = {
  vus: 50,
  duration: '30s',
};

export default function () {
  http.get('https://yourdomain.com/');
  sleep(1);
}

k6 run test.js

k6 supports realistic multi-step scenarios (browse, add to cart, checkout) rather than hammering a single URL — more representative of real user behavior.

Monitoring During the Load Test

Run your monitoring dashboard (Netdata, htop) simultaneously in another session so you can watch exactly where resources max out as load increases:

htop

Testing from a Separate Server

Run the load testing tool from a different VPS than the one being tested — testing from the same server that's receiving the load produces misleading results, since the test tool itself consumes resources on the target.

Gradually Increasing Load

Start with modest concurrency and increase gradually, rather than immediately hammering the server at maximum expected traffic — this reveals the specific point where performance starts degrading, not just whether it survives the absolute peak.

What to Do with the Results

• If the database is the bottleneck, see How to Tune MySQL/MariaDB Performance for a VPS
• If it's CPU-bound, consider upgrading, or optimizing slow code paths — see How to Profile and Optimize Slow Application Requests
• If a single server clearly can't handle projected peak load, consider load balancing — see How to Set Up Basic Load Balancing with Nginx

Common Errors

Test tool itself becomes the bottleneck — run from a separate, adequately resourced machine, not the same server being tested or an underpowered testing client.

Best Practices

• Only test infrastructure you own or have explicit permission to test
• Run tests from a separate server
• Increase load gradually and monitor throughout, not just checking pass/fail at the end
• Re-test after applying fixes to confirm improvement

Related Articles

• How to Diagnose a Slow VPS: Complete Performance Checklist
• How to Set Up Basic Load Balancing with Nginx
• How to Profile and Optimize Slow Application Requests