Load testing in Rest API - Step-by-Step Execution

Concept Flow - Load testing

Start Load Test

↓

Send Multiple Requests

↓

Measure Response Times

↓

Check Server Behavior

↓

Analyze Results

↓

Report Performance

Load testing sends many requests to a server to check how it handles traffic and measures response times.

Execution Sample

Rest API

for i in range(5):
    response = send_request()
    print(f"Request {i+1}: {response.status_code}")

This code sends 5 requests to a server and prints each response status code.

Execution Table

Request Number	Action	Response Status	Response Time (ms)	Server Load
1	Send request 1	200	120	Low
2	Send request 2	200	130	Low
3	Send request 3	200	125	Medium
4	Send request 4	200	140	Medium
5	Send request 5	200	150	High
-	All requests sent	-	-	Server stable

💡 All 5 requests completed with status 200; server handled load without errors.

Variable Tracker

Variable	Start	After 1	After 2	After 3	After 4	After 5	Final
i (request count)	0	1	2	3	4	5	5
response.status_code	-	200	200	200	200	200	200
response_time_ms	-	120	130	125	140	150	150
server_load	Low	Low	Low	Medium	Medium	High	High

Key Moments - 2 Insights

Why does the server load increase even though the response status stays 200?

The server load reflects how busy the server is handling requests, but a status 200 means it successfully processed each request regardless of load, as shown in the execution_table rows 3 to 6.

Why do response times increase with more requests?

As more requests are sent, the server works harder, causing response times to rise, visible in the response_time_ms values increasing from 120 to 150 ms in the variable_tracker.

Visual Quiz - 3 Questions

Look at the execution_table, what is the response time for the 3rd request?

A 140 ms

B 130 ms

C 125 ms

D 150 ms

💡 Hint

Check the 'Response Time (ms)' column for Request Number 3 in the execution_table.

At which request number does the server load first become 'Medium'?

A Request 3

B Request 2

C Request 4

D Request 5

💡 Hint

Look at the 'Server Load' column in the execution_table to find when it changes from 'Low' to 'Medium'.

If the response time for request 5 was 200 ms instead of 150 ms, how would the variable_tracker change?

A The 'response.status_code' would change to 500

B The 'response_time_ms' after 5 would be 200 instead of 150

C The 'server_load' would change to 'Low'

D The variable 'i' would be 6

💡 Hint

Check the 'response_time_ms' row in variable_tracker for the value after 5 requests.

Concept Snapshot

Load testing sends many requests to a server to check performance.
It measures response times and server load.
Status 200 means success even under load.
Response times usually increase as load grows.
Helps find how many users a server can handle.

Full Transcript

Load testing is a way to check how a server behaves when many users send requests at once. The process starts by sending multiple requests, measuring how long each takes, and watching how busy the server becomes. In the example, five requests are sent one after another. Each request gets a status code 200, meaning success. The response times grow from 120 ms to 150 ms, showing the server is working harder. The server load changes from low to high as more requests come in. This helps understand the server's limits and performance under stress.

Practice

1. What is the main purpose of load testing in REST APIs?

easy

A. To check how many users the API can handle at once

B. To find syntax errors in the API code

C. To improve the API's user interface design

D. To add new features to the API

Solution

1. Step 1: Understand load testing goal

   Load testing is done to see how many users or requests an API can handle simultaneously without failing.

2. Step 2: Compare options with load testing purpose

   Only To check how many users the API can handle at once talks about handling many users at once, which matches load testing's main goal.

3. Final Answer:

   To check how many users the API can handle at once -> Option A

4. Quick Check:

   Load testing = check user load [OK]

Hint: Load testing measures user capacity, not code errors [OK]

Common Mistakes:

• Confusing load testing with debugging
• Thinking load testing improves UI
• Assuming load testing adds features

2. Which of the following is the correct way to start a basic Locust load test script?

easy

A. from locust import User

class MyUser(User):
def run():
get('/')

B. import locust

class MyUser:
def task():
client.get('/')

C. from locust import HttpUser, task

class MyUser(HttpUser):
@task
def load(self):
self.client.get('/')

D. from locust import HttpUser

class MyUser(HttpUser):
def test():
self.get('/')

Solution

1. Step 1: Identify correct Locust import and class

   The Locust library uses HttpUser and @task decorator to define user behavior.

2. Step 2: Check method and client usage

   from locust import HttpUser, task class MyUser(HttpUser): @task def load(self): self.client.get('/') correctly uses HttpUser, @task, and self.client.get('/'). Other options miss correct imports or method calls.

3. Final Answer:

   from locust import HttpUser, task class MyUser(HttpUser): @task def load(self): self.client.get('/') -> Option C

4. Quick Check:

   Use HttpUser and @task decorator [OK]

Hint: Look for HttpUser and @task decorator to spot correct syntax [OK]

Common Mistakes:

• Missing @task decorator
• Using wrong class name like User instead of HttpUser
• Calling get() without self.client

3. What will be the output when running this Locust test snippet?

from locust import HttpUser, task

class MyUser(HttpUser):
    @task
    def index(self):
        self.client.get("/home")

# Simulate 10 users making requests concurrently

medium

A. No requests will be sent because task is missing

B. 10 users will send GET requests to /home concurrently

C. Syntax error due to missing main function

D. Only 1 user will send a GET request to /home

Solution

1. Step 1: Understand Locust user simulation

   Locust simulates multiple users running the tasks concurrently when configured to do so.

2. Step 2: Analyze the code behavior

   The class defines a task sending GET requests to /home. If run with 10 users, all will send requests concurrently.

3. Final Answer:

   10 users will send GET requests to /home concurrently -> Option B

4. Quick Check:

   Locust simulates multiple users running tasks [OK]

Hint: Tasks run concurrently for all simulated users [OK]

Common Mistakes:

• Thinking only one user runs the task
• Assuming missing main causes syntax error
• Believing tasks won't run without explicit start

4. Identify the error in this Locust test code:

from locust import HttpUser, task

class MyUser(HttpUser):
    def index(self):
        self.client.get("/")

medium

A. Class name should be lowercase

B. HttpUser class should be imported from requests

C. self.client.get should be self.get

D. Missing @task decorator before index method

Solution

1. Step 1: Check for task decorator usage

   Locust requires the @task decorator on methods to mark them as tasks to run.

2. Step 2: Verify other parts of the code

   HttpUser is correctly imported, self.client.get is correct, and class names are capitalized by convention.

3. Final Answer:

   Missing @task decorator before index method -> Option D

4. Quick Check:

   Tasks need @task decorator [OK]

Hint: Always add @task decorator to methods to run as tasks [OK]

Common Mistakes:

• Forgetting @task decorator
• Importing HttpUser from wrong module
• Using self.get instead of self.client.get

5. You want to test your REST API's login endpoint under heavy load using Locust. Which approach best simulates realistic user behavior?

hard

A. Create a task that sends POST requests with different user credentials and add wait times between requests

B. Send continuous GET requests to the login endpoint without any delay

C. Run a single user sending POST requests in a tight loop

D. Only test the API with one user to avoid server overload

Solution

1. Step 1: Understand realistic load testing

   Realistic load testing simulates many users with varied data and natural pauses between actions.

2. Step 2: Evaluate options for realism

   Create a task that sends POST requests with different user credentials and add wait times between requests uses different credentials and wait times, mimicking real user behavior. Others either overload or under-test the API.

3. Final Answer:

   Create a task that sends POST requests with different user credentials and add wait times between requests -> Option A

4. Quick Check:

   Use varied data and wait times for realism [OK]

Hint: Add wait times and varied data for realistic load [OK]

Common Mistakes:

• Sending requests nonstop without delay
• Testing with only one user
• Using only GET requests for login