Little’s Law: John Dutton Conant Little, is an Institute Professor at the Massachusetts Institute of Technology, best known for his result in Operations Research, Little’s Law. Little’s law is truly amazing in its simplicity and can be used to describe the most complex of systems including resources within those systems.
Let’s take for example the system described above. The notations used include:
- N – Number of users present within the system
- C – Number of completions
- X – Throughput or Rate of Departure
- A – Number of Arrivals
- λ – Rate of Arrival
- Rt – Time spent by Customers within the system
Little’s Law basically states that the long-term average number of customers in a stable system N is equal to the long-term average effective arrival rate, λ, multiplied by the average time a customer spends in the system, W or Rt, or expressed algebraically:
- N = λ * Rt ……………….. [ N = Number of Users in the System, Rt = Response Time, λ = Arrival Rate ]
Little’s Law can also be stated as:
- N = Rt * X ……………….. [ N = Number of Users in the System, Rt = Response Time, X = Throughput ]
For a system where Zt (Think Time is Non Zero) Little’s Law can be stated as:
- N = [Rt + Zt] * X ……………….. [ N = Number of Users in the System, Rt = Response Time, Zt = Think Time, X = Throughput ]
Applying Little’s Law: Now that we’ve just defined Little’s Law let’s take a look at where we could apply Little’s Law and benefit from a better understanding of our systems including user behavior on our existing systems.
Little’s Law can be applied to the following scenarios:
- Model Performance Testing Workload
- Validate Performance Testing Results
- Validate the Sizing Models that your Infrastructure guys have come up with
- Validate the Non Functional Requirements that your Architects have recommended
Let’s take a look at a few examples and apply Little’s Law to a real world system:
Example – Determine Concurrent Users Using Little’s Law: A system at peak processes 8000 Transactions/Hour with an average response time of ~5s per transaction. The average Think Time per user is ~30s. What is the number of concurrent users on the system?
- Throughput or X = 8000/3600 = 2.22 TPS
- We know: N = [Rt + Zt] * X ……….. [ N = Number of Users in the System, Rt = Response Time, Zt = Think Time, X = Throughput ]
- Applying the equation: N = [ Rt + Z ] * X = [ 5 + 30 ] * 2.22 = 77.7
- The above system has approximately 77 users at peak driving 8000 Transactions/Hour.
Example – Validate System Performance Testing Results: The outcome of a performance test is as follows:
- Peak User Concurrency = 1000
- Average Transactional Response Time = 5s
- Average User Think Time = 40s
- Peak Transactional Throughput ( as recorded by the tool) = 500 TPS
We know: N = [Rt + Zt] * X ……….. [ N = Number of Users in the System, Rt = Response Time, Zt = Think Time, X = Throughput ]
- Applying the equation: X = N / [ Rt + Z ] = 1000 / [ 5 + 40 ] = 22.22 TPS
You know from the above results, something is really wrong. Little’s Law suggests that the actual TPS for the above system should be ~22 TPS but the Performance Testing results show transactional throughput as 500 TPS. Could this be errors in the Performance Testing results due to poorly written scripts? If your scripts are not smart enough to catch all the relevant errors, the Performance Testing tool will include the errors as part of the true transactional throughput.
The above two examples are meant to give you some familiarity with Little’s Law and help you apply Little’s Law to model Performance Testing workload including validating your Performance Testing results.
Modeling Systems & Forecasting Performance : To teach yourself the concepts of Performance Modeling & to experience how easy Forecasting System Performance could be, please visit VisualizeIT.