A performance test without pass/fail criteria is just a monitoring exercise. You need SLAs -- Service Level Agreements -- that define what "good enough" means. Without SLAs, every test result leads to a debate. "Is 2.5 seconds acceptable?" "Maybe. Probably. Let us ask the product manager." SLAs end the debate before it starts.
A good SLA is specific, measurable, and tied to business requirements. "The app should be fast" is not an SLA. "The login API p95 response time should be under 1 second with 500 concurrent users and error rate below 0.1%" is an SLA.
# Performance SLAs -- Shopping Portal
## Load Test (Expected Traffic: 500 concurrent users)
| Endpoint | p95 Response Time | Max Error Rate | Min Throughput |
|-----------------------|-------------------|----------------|----------------|
| GET /products | < 2 seconds | < 0.5% | 200 RPS |
| GET /products/:id | < 1 second | < 0.5% | 100 RPS |
| POST /cart | < 500ms | < 0.1% | 50 RPS |
| POST /checkout | < 3 seconds | < 0.01% | 20 RPS |
| POST /login | < 1 second | < 0.1% | 100 RPS |
## System Resources (at 500 concurrent users)
- CPU utilization: < 70%
- Memory utilization: < 75%
- Database connection pool: < 80% of max
## Recovery
- After load spike (5x normal): return to normal p95 within 2 minutes
## Availability
- Zero downtime during test execution
- Error rate never exceeds 1% at any point during the test| Operation Type | p95 Target | Error Rate | Rationale |
|---|---|---|---|
| Read operations (GET) | < 1-2 seconds | < 0.5% | Users expect fast reads -- browsing, searching |
| Write operations (POST/PUT) | < 2-3 seconds | < 0.1% | Writes affect data -- errors are more costly |
| Financial transactions | < 3 seconds | < 0.01% | Compliance and trust -- failures lose customers |
| File operations | Size-dependent | < 0.5% | Large files are slow -- users tolerate with progress indicator |
| Authentication | < 1 second | < 0.1% | First impression -- slow login = "the app is slow" |
| Search | < 2 seconds | < 0.5% | Users expect near-instant search results |
The best SLAs are enforced automatically. Most performance tools support threshold checks that fail the test when SLAs are violated.
import http from 'k6/http';
import { sleep } from 'k6';
export const options = {
vus: 500,
duration: '30m',
thresholds: {
// p95 response time must be under 2 seconds
http_req_duration: ['p(95)<2000'],
// Error rate must be under 1%
http_req_failed: ['rate<0.01'],
// Specific endpoint SLA
'http_req_duration{name:login}': ['p(95)<1000'],
'http_req_duration{name:checkout}': ['p(95)<3000'],
},
};
export default function () {
http.get('https://myapp.com/products', { tags: { name: 'products' } });
sleep(5);
}Start with loose SLAs and tighten over time. If you have no performance data, set initial SLAs at p95 < 3 seconds and error rate < 1%. Run the first test. If you hit 800ms at p95, tighten to p95 < 1.5 seconds. Iteratively tighten until you find the realistic limit. Starting too tight leads to constant false failures.
Q: How do you define performance SLAs for a new application?
A: I start by gathering requirements from three sources: business (what response time will users tolerate?), industry benchmarks (Google recommends LCP under 2.5s), and competitor analysis. Then I run a baseline test at low load to establish the current performance floor. I set initial SLAs at 2-3x the baseline: if login takes 200ms at low load, the SLA under full load might be p95 < 600ms. SLAs are per-endpoint with specific metrics: p95 response time, error rate, and minimum throughput. I automate SLA checks in the test tool (k6 thresholds, JMeter assertions) so tests fail automatically when SLAs are violated. We review and tighten SLAs quarterly based on actual performance data.
Key Point: SLAs are per-endpoint, specific (p95 < 2s, errors < 0.1%), and derived from business requirements plus baseline measurements. Automate SLA checks in your test tool. Start loose, tighten iteratively.
Key Point: Define SLAs per-endpoint with specific thresholds. Derive from business needs + baselines. Automate checks. Start loose, tighten over time.