Little’s Law in Performance Testing

In 1954, John Little published a paper in which he described the queueing theory by a new law. Later, it is named Little’s Law. He formulated 3 basic terms: the average number of customers, customer arrival rate and the average time spent by a customer in the system and expressed algebraically the law is:

L = λ * W

The same formula was accepted in the performance testing to simulate the real-world load in the testing environment, he above formula in the performance testing term relates 3 basic metrics of performance testing which are the number of users, transaction rate and response time.

Little’s Law states: L=λ×W

Where:

L = Average number of users in the system (concurrent users)

λ (Lambda) = Arrival rate (requests per unit time, e.g., requests per second)

W = Average response time (time a user spends in the system)

??These concepts serve as the fundamental building blocks of performance testing. Below is a detailed explanation with real-world examples:

• Concurrent Users/User Load: The number of virtual users applying load on the system.
• Response Time: The total time taken by the system to respond to a request, including network latency.
• User Journey (Iteration): The sequence of user actions on the application (e.g., Home → Login → Search → Checkout → Logout).
• Transaction: A specific user action within an iteration.
• Think Time: The time a user spends on a page before the next action (e.g., 5s reading a product description).
• Pacing: A delay between user journeys to regulate test load (e.g., 30s pacing after a 60s journey = 90s total cycle).

Lets take a scenario - An e-commerce website expects 500 concurrent users during peak load, Each user sends 2 requests per minute (arrival rate = 1000 requests per minute), The system’s average response time is 2 seconds per request.

We need to verify if the system can maintain this load, here λ=1000?requests?per?minute which is 16.67?requests?per?second.

Applying Little’s Law---> L=λ×W

L=16.67×2=33.34

The system is expected to have 33.34 concurrent users actively making requests at any given time, However, the business requirement is 500 concurrent users, meaning either the arrival rate or response time assumptions need to be adjusted.

Adjusting for the Required Load (500 Users)

If we need 500 concurrent users, we solve for λ (arrival rate): λ=LW=500/2=250?requests?per?second.

Conclusion:

• To support 500 concurrent users, the system must handle 250 requests per second
• If the system is only processing 16.67 requests per second, it might be under-provisioned and need scalability improvements.

If any metric (load, request rate, response time) changes, the others must adjust accordingly to maintain a valid simulation, consider these cases as well-

Applying Think Time

Users typically spend time on each page before moving to the next step (e.g., reading product details, reviewing the cart).

Revised Assumptions with Think Time:

• Each user takes 8 seconds of think time before the next action.
• Response time = 2 sec per request
• Think time = 8 sec per request
• Total time per request = 10 sec

New Arrival Rate (λ) with Think Time

λ= L/( W+Think?Time)=500/(2+8)=50 request per second.

Result: The system now sees only 50 requests per second instead of 250, which is more realistic.

?Applying Pacing

Pacing is an intentional delay between user journeys to ensure a steady test load rather than overwhelming the server.

Revised Assumptions with Pacing:

• A user completes the entire journey (6 steps) in 60 seconds
• Pacing of 30 seconds is applied before starting the next iteration

New Arrival Rate (λ) with Think Time & Pacing:

• Total journey time = 60 sec + 30 sec (Pacing) = 90 sec
• Each user completes 1 iteration per 90 seconds
• λ (per user) = 1/90 requests per second
• With 500 users

λ=500*(1/90)= 5.56?requests?per?second

Results: The system now sees only 5.56?requests per second?.

Final Comparison :

• Any change in one metric (load, arrival rate, or response time) will impact the others.
• An increase in response time leads to more concurrent users in the system, which may result in performance bottlenecks.
• Real-world scenarios require incorporating pacing and think time, as users do not send requests continuously.

If you found this content helpful, feel free to follow me https://www.dhirubhai.net/in/arjunkrm-testarchitect/ for more insights!?