Stress Testing

Stress testing deliberately drives a system past its designed limits, with more users, requests, or data than it was built for. Unlike a load test, the aim is not to confirm that it copes, but to discover where and how it breaks.

Why it matters

Real traffic does not respect your capacity plan. A viral link, a bot, or a retry storm can send ten times the usual load. Knowing the failure mode ahead of time matters as much as knowing the limit. A system that slows down and sheds load is far better than one that crashes and corrupts data.

Example

You raise load in steps while watching key signals:

100 users:   p95 300 ms, errors 0%
500 users:   p95 650 ms, errors 0%
1000 users:  p95 2.4 s,  errors 3%   <- knee of the curve
1500 users:  p95 9 s,    errors 40%, DB connections exhausted

The knee at around 1,000 users is your practical ceiling. After the test, drop the load back down and verify the system recovers on its own without a restart.

Common mistakes

• Stopping at the first failure instead of recording what failed and why.
• Skipping the recovery phase. Many systems fail on the way down, not up.
• Running against shared infrastructure that affects other teams or customers.
• Confusing it with load testing, which validates expected demand.

Related

• Load testing
• Load shedding
• Saturation
• Chaos engineering

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.