Load testing, scaling strategies, and capacity planning for Clay integrations.
| Metric | Warning | Critical |
|---|---|---|
| CPU Utilization | > 70% | > 85% |
| Memory Usage | > 75% | > 90% |
| Request Queue Depth | > 100 | > 500 |
| Error Rate | > 1% | > 5% |
| P95 Latency | > 1000ms | > 3000ms |
Write a k6 test with ramp-up (2m to 10 VUs), steady state (5m), stress (2m to 50 VUs), and ramp-down stages. Set thresholds: P95 < 500ms, error rate < 1%.
Set up Kubernetes HPA targeting 70% CPU utilization, 2-20 replicas, with custom metric on queue depth.
Use generic-pool with 5-20 connections and 30s idle timeout to reuse Clay client connections.
k6 run --env CLAY_API_KEY=${CLAY_API_KEY} clay-load-test.js
Record results in the benchmark template: total requests, success rate, P50/P95/P99 latency, max RPS.
For complete k6 scripts, HPA YAML, connection pool code, and capacity estimator, load the reference guide:
Read(${CLAUDE_SKILL_DIR}/references/implementation-guide.md)
| Issue | Cause | Solution |
|---|---|---|
| k6 timeout | Rate limited | Reduce RPS |
| HPA not scaling | Wrong metrics | Verify metric name |
| Connection refused | Pool exhausted | Increase pool size |
| Inconsistent results | Warm-up needed | Add ramp-up phase |
For reliability patterns, see clay-reliability-patterns.
Basic usage: Apply clay load scale to a standard project setup with default configuration options.
Advanced scenario: Customize clay load scale for production environments with multiple constraints and team-specific requirements.