Load testing in Rest API - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this simple load test script?

Consider this Python script using the requests library to simulate 3 sequential API calls. What will be printed?

Rest API

import requests

urls = ['https://api.example.com/data1', 'https://api.example.com/data2', 'https://api.example.com/data3']

for url in urls:
    response = requests.get(url)
    print(response.status_code)

A

200
200
200

B

200
404
200

C

404
404
404

D

200
200
404

💡 Hint

Assume all URLs are valid and the server is up.

The script sends GET requests to three valid endpoints. Since the server is up and URLs are correct, each request returns HTTP status 200.

🧠 Conceptual

intermediate

Which factor is most important when designing a load test?

When creating a load test for a REST API, which factor should you prioritize to simulate real user behavior?

A The programming language used to write the test

B Only the total number of requests sent

C The size of the API response payload

D Number of concurrent users and request rate

💡 Hint

Think about what affects server load the most.

The number of concurrent users and how fast requests are sent directly impact server load and performance under stress.

🔧 Debug

advanced

Why does this load test script fail with a connection error?

This Python script uses threading to send 100 requests concurrently but raises a ConnectionError. What is the likely cause?

Rest API

import threading
import requests

def send_request():
    requests.get('https://api.example.com/data')

threads = []
for _ in range(100):
    t = threading.Thread(target=send_request)
    threads.append(t)
    t.start()

for t in threads:
    t.join()

A The URL is invalid causing connection failure

B The requests library does not support threading

C The server limits the number of simultaneous connections causing errors

D Threads are not started properly

💡 Hint

Consider server-side limits on connections.

Many servers limit concurrent connections from a single client. Sending 100 requests at once may exceed this limit, causing connection errors.

📝 Syntax

advanced

Identify the syntax error in this load test script snippet

What is wrong with this Python code snippet for sending multiple requests?

Rest API

import requests

responses = [requests.get('https://api.example.com/data') for i in range(5)]
print(responses.status_code)

A 'responses' is a list; accessing 'status_code' directly causes AttributeError

B Missing parentheses in the print statement

C The range function is used incorrectly

D The requests.get call is missing required headers

💡 Hint

Think about the type of 'responses' and how to access elements.

'responses' is a list of response objects. You cannot call 'status_code' on the list itself; you must access an individual response first.

🚀 Application

expert

How many requests per second does this load test generate?

This script uses asyncio to send 50 requests with a 0.1 second delay between each start. How many requests per second does it generate approximately?

Rest API

import asyncio
import aiohttp

async def fetch(session, url):
    async with session.get(url) as response:
        return await response.text()

async def main():
    async with aiohttp.ClientSession() as session:
        tasks = []
        for _ in range(50):
            tasks.append(fetch(session, 'https://api.example.com/data'))
            await asyncio.sleep(0.1)
        await asyncio.gather(*tasks)

asyncio.run(main())

A 50 requests per second

B 10 requests per second

C 5 requests per second

D 100 requests per second

💡 Hint

Calculate how many requests start each second based on the delay.

Each request starts after 0.1 seconds, so 1/0.1 = 10 requests start per second approximately.

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