تحديد أهداف الأداء واتفاقيات مستوى الخدمة

Running a load test without a goal just produces numbers. To judge pass or fail you first need clear, agreed performance goals.

Three related terms:

• SLI: a measured indicator (e.g. response time)
• SLO: an internal target for that indicator
• SLA: a contractual promise to customers

Define latency goals in percentiles, not averages. For example: p95 under 400 ms, p99 under 800 ms. Percentiles capture the experience of your slowest users.

State how many requests per second the system must handle, derived from expected peak traffic plus a safety margin.

Set an acceptable error rate, often well under 1%. An error budget defines how much failure you tolerate before action is required.

Base targets on production data: peak concurrent users, busiest hour, and growth forecasts. Goals pulled from thin air lead to misleading tests.

Beyond user-facing metrics, set ceilings for CPU, memory, and connection pools (e.g. stay below 70% CPU at peak) to leave headroom for spikes.

Modern tools let you encode goals as pass/fail thresholds so a run is automatically graded.

Run a small baseline test to learn current behavior. Targets should be ambitious yet achievable relative to that baseline.

Performance goals are a business decision as much as a technical one. Agree them with product and operations so a failed test means the same thing to everyone.

Avoid:

• Measuring averages instead of percentiles
• Targets with no link to real traffic
• Ignoring error rate and resource limits
• No agreed definition of pass/fail

Test your performance-goal knowledge.

You learned to set targets:

• SLI measures, SLO targets, SLA promises
• Define latency as percentiles, plus throughput and error budgets
• Derive goals from real traffic and a baseline
• Encode goals as automatic pass/fail thresholds