New Webinar: Modernising Without Destabilising: How Bread Financial Is Building Confidence Through Change

Learn more

New webinar with Bread Financial

Learn more
Contact us

Blogs

Using Little’s Law to set Think Times in Performance Testing

<span id="hs_cos_wrapper_name" class="hs_cos_wrapper hs_cos_wrapper_meta_field hs_cos_wrapper_type_text" style="" data-hs-cos-general-type="meta_field" data-hs-cos-type="text" >Using Little’s Law to set Think Times in Performance Testing</span>

Date 29 June 2026

Author Team Capacitas

Introduction

We are currently working on performance testing a new application for a client. An existing application has been re-architected to use new technologies and adopting RESTful HTTP protocols.

We had access to data from the live site and generated forecasting figures.

Planning

We created some scripts that emulated a user journey through the new application. Before we were able to begin performance testing we needed to see what throughput we were required to achieve.

There is a formula we can use to calculate the throughput that we require.

Little’s Law

L - Lead Time

λ – Throughput

W – Response Time

L - Lead Time

The amount of time spent by an object in a queue. E.g. The number of customers queuing to pay at a till

λ - Throughput

The average arrival rate. E.g. The amount of customers being served at the till per second

W – Response Time

The average time an object spends in the system. E.g. the time a customer has spent from the time they entered the queue to the time they have been served at a till

Calculating

We already had figures from the production system; we could see the required throughput we would require per second. In this case we were required to achieve a throughput of 2.37TPS (Transactions per second)

After our planning was complete we knew that our overall response time (from beginning to end of the system) was 4.3s. We also knew the throughput we were required to achieve was 2.37TPS and finally we can calculate lead time by using these 2 values.

So from this we get the following values.

λ = 2.37TPS, W = 4.52s

Therefore L = 10.7

So now we had a complete formula. So we now knew that with 10.7Vusers we could achieve the required TPS rate which would be our constant.

However we were performance testing and it was vital we put a realistic number of users through the system.

We wanted to run a test with 50 Vusers on the system therefore we knew that λ would be constant and we would alter W accordingly.

If we set L to 1 we then know that W is 0.422

From this we can multiply both sides by 50. Which gives us the following formula:

50 = λ *21.12

Think Times

So now we have everything to calculate the think times required for a 50 Vuser performance test to achieve a set throughput.

W is equal to 21.12s and we know that the overall response time for a single user is 4.52s.

So we simply subtract the response time for a single user away from the response time with 50 Vusers.

Which gives us:

21.12s – 4.52s = 16.6s

So we now know that we require 16.6s think time in our performance testing scripts to ensure a realistic result.

Team Capacitas
About the author

Team Capacitas

Capacitas is a cloud and AI value partner. We translate rapid technological change into enduring commercial advantage by converting every unit of compute into enterprise value.

FinOps and AI: Building the Financial Discipline for the Next Wave of Enterprise Intelligence

AI FinOps represents an evolution rather than a replacement of traditional FinOps. It extends the model into a domain where financial, technical, and product decisions are tightly interconnected.

Read insight

Confidence Under Load: How We Verified AKS Readiness for Peak

How Capacitas verified AKS readiness for peak demand by validating workload performance, autoscaling, cluster capacity, monitoring, and incident response.

Read insight

Building Cloud Resilience: Lessons from the AWS Outage

Learning from the Latest Outage. Events like this week’s AWS disruption highlight one clear truth: resilience must be designed, not assumed.

Read insight

Bringing Order to Chaos: A Practical Guide to Chaos Testing in the Cloud

In today’s cloud-native environments, resilience is not optional—it’s critical. Chaos testing has emerged as a key practice for validating system behaviour under failure conditions.

Read insight