patterntypescriptnoneModerate
Performance Testing with k6 or autocannon
Viewed 0 times
load testingk6autocannonperformance testingthroughputp95virtual users
Problem
APIs pass functional tests but fail under load. Performance regressions are discovered in production rather than during development.
Solution
Use k6 or autocannon for load testing as part of CI or pre-release checks.
// k6 load test script (k6.io)
import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
stages: [
{ duration: '30s', target: 10 }, // Ramp up to 10 VUs
{ duration: '1m', target: 10 }, // Stay at 10 VUs
{ duration: '10s', target: 0 }, // Ramp down
],
thresholds: {
http_req_duration: ['p(95)<500'], // 95% of requests < 500ms
http_req_failed: ['rate<0.01'], // Error rate < 1%
},
};
export default function() {
const res = http.get('http://localhost:3000/api/users');
check(res, {
'status is 200': (r) => r.status === 200,
'response time < 200ms': (r) => r.timings.duration < 200,
});
sleep(1);
}
// Run: k6 run script.js# autocannon for quick HTTP benchmarking
npx autocannon -c 100 -d 30 http://localhost:3000/api/users
# -c: concurrent connections
# -d: duration in secondsWhy
Load testing reveals performance characteristics that unit tests cannot: database connection pool exhaustion, memory leaks under sustained load, and response time degradation at scale.
Gotchas
- Load test against a staging environment that matches production — local tests are not representative.
- Always run load tests with a warm-up period — cold start latency skews results.
- Monitor database query performance, not just HTTP response times — the bottleneck is often the DB.
Revisions (0)
No revisions yet.