🧪 Stress Test in Computer Science: What it is, What it is for and How to do it

Posted by

  


In computing, one of the most effective ways to ensure the stability and reliability of a system is to subject it to a stress test. Whether you're developing an API, running an e-commerce business, or deploying an application in the cloud, knowing how your system performs under extreme load is crucial.

In this article, you'll learn:

  • What is a computer stress test

  • How is it different from other load tests

  • Why it matters

  • How to do a Stress Test

  • Tools for Stress Testing

  • How to set up a test with real tools (JMeter, Locust, k6)

  • Practical examples and interpretation of results

🔗 Do you like Techelopment? Check out the site for all the details!

✅ What is Stress Testing in Computer Science

A stress test is a type of performance test that aims to evaluate the resilience of a system by taking it beyond its maximum expected load. It helps you understand how and when the system fails, so you can intervene before it happens in production.

In other words: how much can it tolerate before it gives up?

🧠 Main objectives:

  • Verify the behavior of the system under extreme conditions

  • Discover scalability limits and bottlenecks

  • Identify breaking points (crashes, timeouts, errors)

  • Test the ability to recover from failure


🔍 Differences with other test types

Test Type Description
Load Test Measures performance under an expected load or slightly above it
Stress Test Puts the system beyond its limits to assess how it degrades or fails
Spike Test Simulate sudden traffic spikes
Soak Test Verify stability under load prolonged over time


🧠 Why do a Stress Test

Doing a stress test means anticipating problems that could occur in critical conditions:

  • Preventcrash during high traffic events (e.g. Black Friday, product launches)

  • Check servers for DDoS attacks or unexpected spikes

  • Ensure that message queues, caches or databases do not become saturated

  • Demonstrate the scalability of the app (how much load it can handle)

  • Identify memory leaks, concurrency errors, network failures


⚙️ How to Stress Test: Key Steps

1. 🎯 Goal Definition

  • What do I want to test? (e.g. REST API, backend, website)

  • What are the expected limits? (e.g. 10,000 requests per minute)

  • What metrics should I monitor? (e.g. response time, CPU usage, 5xx errors)

2. 🧪 Preparing the test environment

  • Use a staging environment (similar to production but isolated)

  • Have monitoring tools active (Grafana, New Relic, Prometheus)

  • Set up detailed logs, alerts, and automatic snapshots

3. 🛠️ Stress simulation

Using test tools, requests are generated to the system in a progressive or explosive way:

  • Gradual increase up to the theoretical limit

  • Sudden spikes (e.g. from 0 to 5,000 users in 1 minute)

  • Prolonged persistence of maximum load

4. 📊 Monitoring Results

The most important metrics to watch:

  • Average Response Time

  • Percentage of errors

  • Throughput rate (requests per second)

  • Resource utilization (CPU, RAM, bandwidth, disk)

  • System stability (crashes, timeouts, hangs)

5. 🔁 Analysis and optimization

If the system fails (and it does), you should:

  • Analyze the error logs

  • Find primary causes of collapse

  • Optimize code, configurations, infrastructure

  • Repeat the test until the system is under acceptable load


🧰 Stress Test Tools

Here are some of the most commonly used tools for stress testing:

🔸 Apache JMeter

  • Free, open-source

  • Supports HTTP testing, database, SOAP, FTP, TCP, etc.

  • Great for testing RESTful APIs or websites

🔸 Locust

  • Python based, very flexible

  • Define scenarios in code

  • Great for modern, dynamic testing

🔸 Gatling

  • Powered by Scala

  • Detailed graphical reports

  • Efficient for long-term testing

🔸 Artillery

  • Modern command line tool (Node.js)

  • Easy to integrate into CI/CD (GitHub Actions, GitLab CI)

🔸 k6 (by Grafana)

  • Based tests on JavaScript script

  • Great for DevOps integration and pipelines


💡 Practical Example with k6

Scenario:

A company wants to test an API /products that typically serves 1,000 requests per minute. You want to know how long it will last before it starts responding with errors or excessive slowdowns.

📦 Requirements:

No external runtime installation (like Java or Python): k6 is a standalone binary written in Go.

It can be installed via:

File k6.js:

import http from 'k6/http';
import { check } from 'k6';

export let options = { 
   stages: [ 
      { duration: '2m', target: 100 }, // increase to 100 users 
      { duration: '5m', target: 500 }, // constant stress at 500 users 
      { duration: '1m', target: 0 }, // ramp-down 
   ],
};

export default function () { 
   let res = http.get('https://api.enterprise.it/products'); 
   check(res, { 
      'status is 200': (r) => r.status === 200, 
      'time < 500ms': (r) => r.timings.duration < 500, 
   });
}

▶️ Starting the test:

k6 run k6.js

Monitoring:

  • If more than 400 users start generating 503 errors → possible server capacity limit

  • If response times exceed 2 seconds → necessary optimize database or increase resources


🧪 Practical Example with Apache JMeter

🔧 Scenario:

We want to stress an HTTP endpoint (https://api.enterprise.it/products) to simulate 1,000 concurrent users, each of which makes requests in a loop.

📦 Requirements:

  • Apache JMeter installed (download here)

  • Java installed

  • JMeter graphical UI or non-GUI mode for server environments

▶️ Configuration in JMeter (via GUI):

1. Thread Group

Central element that defines the test load.

  • Number of Threads (users): 1000
    → Simulate 1000 virtual users.

  • Ramp-Up Period (in seconds): 60
    → It means JMeter will spread the startup of 1000 users over 60 seconds.
    If 1000 users in 60 seconds, it starts ~16.6 per second.
    Purpose: avoid that all the load starts at the same time.

  • Loop Count: 10
    → Each user will execute 10 times the sequence of requests (in our case, call to /products).
    If you want an infinite load for a certain time, you can use forever.

2. HTTP Request Sampler

  • Method: GET

  • Path: /products

  • Server: api.enterprise.it

3. Listeners

  • Summary Report, View Results Tree, Aggregate Report
    → To analyze average times, throughput, errors.

4. Assertion (optional but useful):

  • Verify that the Response Code is 200

  • Set a maximum acceptable response time (e.g. < 500ms)

▶️ Command line execution (headless mode):

jmeter -n -t stress_test.jmx -l result.jtl -e -o report/

You will get a full HTML report in the report/ folder.

📊 Analysis:

In the generated HTML report you will find:

  • Average response time

  • Error rate

  • Throughput (requests/sec)

  • Response percentiles (e.g. 90°, 95°)


🐍 Stress Test Example with Locust

🔧 Scenario:

Let's simulate 500 concurrent users browsing a site and calling an endpoint /login and then /dashboard. Each user repeats the cycle with random pauses.

📦 Requirements:

  • Python 3

  • Installing Locust:

pip install locust

📄 File locustfile.py:

from locust import HttpUser, task, between

class WebsiteUser(HttpUser): 
   wait_time = between(1, 3) # time to pause between requests 

   @task(1) 
   def login(self): 
      self.client.post("/login", json={"username": "test", "password": "1234"}) 

   @task(2) 
   def dashboard(self): 
      self.client.get("/dashboard")

▶️ Starting the test:

locust -f locustfile.py --host=https://www.enterprise.it

Then visit http://localhost:8089 to access the Locust web interface.

🧪 Run the stress test:

  • Set:

    • Number of users: 500

    • Spaw rate: 50 users/sec

  • Start and observe real-time graphs:

    • Average response time

    • Error rate

    • Throughput

    • Latency percentiles


🆚 JMeter vs Locust (quick comparison)

Feature JMeter Locust
Language XML/UI Python
Curve of alearning Medium-low Medium (requires some code)
Scalability Great (distributed mode) Great (can scale with more workers)
Interface Graphics and CLI Web UI and CLI
DevOps integration Easy with CLI Great in CI/CD pipelines


🧠 Final Thoughts

✅ What to monitor:

  • Average response time

  • HTTP error rates (e.g. 500, 503)

  • CPU/RAM/server usage

  • Database saturation, queues, downstream services

⚠️ What to avoid:

  • Don't test production without control

  • Avoid real data during destructive testing

  • Control costs if you use cloud resources (e.g. temporary instances)

  • Document each step to track improvements over time


📘 Conclusion

The stress test in IT is an indispensable process for building resilient systems, capable of dealing with unexpected situations without collapsing.
Doing them regularly allows not only to identify weak points, but also to build trust in customers and ensure continuity of service in critical moments.



Follow me #techelopment

Official site: www.techelopment.it
facebook: Techelopment
instagram: @techelopment
X: techelopment
Bluesky: @techelopment
telegram: @techelopment_channel
whatsapp: Techelopment
youtube: @techelopment