Little’s Law is very useful for validating given performance targets. You can also use it to add the missing figures from existing requirements. So often, customers provide their user volumes and response-time expectations without any throughput targets—leaving us with an incomplete set of performance requirements. In other situations, we get unrealistic requirements and have to recommend a rework. This post will outline our methodical approach to completing and verifying the given performance targets.
Little’s Law
The basic element’s of Little’s Law are:
N – user
X – transactions or requests per second
R – average response time per request or transaction
Z – average think-time in which the user is viewing results or doing something else
The chart below illustrates how Little’s Law can be applied.
What then, should we do with Little’s Law? What are the use cases for a performance engineer?
Use Little’s Law for your workload modeling
Imagine your business analysts have told you there are 200 transactions per second with an average response time of 20 seconds, and a user think-time of about 5 seconds.
Here’s how Little’s Law can help you calculate the number of concurrent users: N = X C N = 200 x (20 + 5) N = 5000
Thanks to this formula, we’ve calculated the required number of concurrent users and demonstrated that we need to simulate 5,000 such users.
Use Little’s Law to validate performance targets
The best way to handle over-optimistic performance targets is to validate them. Consider a system that has 4,000 concurrent users and a throughput target of 200 user requests per second. You’ve received a performance requirement of average response time of all pages faster than 2 seconds.
Follow these three simple steps to challenge this requirement:
Cycle time: 4000 / 200 = 20 seconds
Calculate think-time: 20 – 2 = 18 seconds
Contact architecture to check if they expect your customers to execute 3 such user requests per minute—this performance target looks unrealistic.
We’ve applied Little’s Law and identified the unrealistic usage figures. We can now go back to the requester to demonstrate our findings and ask for a review of the requirements.
Use Little’s Law to predict the impact of system changes
One of the biggest problems we all face are changes to existing systems. To minimize any adverse effects, architects need to find out how additional features will impact existing applications. As the development stage often lasts for several months, it’s important to understand the effects of new features at the outset. Applying Little’s Law enables you to predict and address any issues.
Consider a project in which your team is planning to add a new reporting feature to the existing OLTP system. Your engineers have provided the figures below:
OLTP: N = 200, C = 20, 2 DB requests per transaction
reporting: N = 50, C = 20, 5 DB requests per transaction
Let’s apply these four steps of Little’s Law and calculate the impact of this system change:
OLTP X = N / C , 200 / 20 = 100 requests per sec
DB X = N / C, 80 / 4 = 20 requests per sec
DB requests per sec: OLTP = 200 , DB = 100
Check if your DB can handle the additional 30% load this new reporting feature will add to your database.
Thanks to Little’s Law, we’ve discovered that the system change will have a massive impact on your database load. And without needing to execute a single load and performance test!
Challenge
Your call center is targeting 1 MIO calls per day, and 80% of these calls come during the 5-hour peak time. The average call duration is 10 minutes. Can your 1,000 employees manage this workload, or will you need to bring in extra staff? If so, how many more team members will you need?
Send your answer and win a nice gift!
Now you understand the tremendous benefits that analyzing performance requirements can bring to your organization. This process will not only help you to assess your design decisions—but also to guide your teams in building applications that are fast and responsive.
Keep up the excellent work! Happy performance engineering!
Comments