c3f43d8b61
- Add 60 new agents across all 10 categories (75 -> 135) - Add 95 new plugins with command files (25 -> 120) - Update all agents to use model: opus - Update README with complete plugin/agent tables - Update marketplace.json with all 120 plugins
1.8 KiB
1.8 KiB
Run a load test against an API endpoint to measure throughput and identify breaking points.
Steps
- Define load test parameters:
- Target URL and HTTP method.
- Concurrent connections (start low, ramp up).
- Duration of the test.
- Request payload and headers.
- Select the load testing tool:
wrkorwrk2for HTTP benchmarking.k6for scripted load tests.ab(Apache Bench) for simple tests.heyfor quick Go-based load tests.
- Run a warm-up phase with low concurrency (10 connections, 10 seconds).
- Execute the main load test in stages:
- Stage 1: Normal load (expected concurrent users).
- Stage 2: Peak load (2x expected).
- Stage 3: Stress test (increase until error rate > 5%).
- Collect metrics at each stage:
- Requests per second (throughput).
- Latency distribution (P50, P95, P99).
- Error rate and error types.
- Resource utilization (CPU, memory) if accessible.
- Identify the breaking point and bottleneck.
- Generate a report with recommendations.
Format
Load Test: <METHOD> <endpoint>
| Stage | Concurrency | RPS | P50 (ms) | P99 (ms) | Errors |
|-------|-------------|-----|----------|----------|--------|
| Normal | 10 | 500 | 20 | 85 | 0% |
| Peak | 50 | 1200 | 45 | 200 | 0.1% |
| Stress | 200 | 800 | 500 | 2000 | 5.2% |
Breaking point: ~150 concurrent connections
Bottleneck: Database connection pool exhaustion
Recommendations:
1. Increase connection pool size from 10 to 50
2. Add connection queuing with backpressure
Rules
- Never run load tests against production without explicit permission.
- Always include a warm-up phase before measuring.
- Ramp up gradually; do not jump to maximum load immediately.
- Record baseline metrics before the test for comparison.
- Stop the test if error rate exceeds 10% to avoid cascading failures.