[twic]

I'm interested by the application of Little's law as a tool for distilling a particular slice through performance down to a single number:

http://en.wikipedia.org/wiki/Little%27s_law

You have a request rate in requests per chronometer-second, and a response time in stopwatch-seconds per request, and you multiply them to get a "demand" figure in stopwatch-seconds per chronometer-second. It's sort of dimensionless, and sort of not, because the seconds on either side of the division operator are sort of orthogonal (very vaguely like how joules per newton-metre is not dimensionless).

How do i use a number like this? Does it make sense to compare the numbers from two different instances of the same system? From instances of two different systems? Should i worry if it goes up? If it goes down? What can i do about it, either way? Is it meaningful to calculate it for component parts of my system, and is there a way to critically relate the values in parts to the whole? Is there a way to relate it to other quantities in my system?

[cpwatson]

From my experience Little's law is typically used to quantify the number of users in the system, a measure of concurrency. For the purpose of our tools we leverage the calculation to provide insight on "offered load" or the time spent w/in the service for a given interval. We do have a challenge in that many of our downstream dependencies are called concurrently. At the current time this prevents us from easily decomposing the demand in a service cleanly among it's dependencies. Some of this has to do with our transaction tracing framework and the granularity at which we require call behavior to be easily time-ordered. We believe we can solve this overtime with an improved framework. In the case of Mogul we leverage the demand calculation to understand who is the largest contributor, pointing us in the direction of possible optimization. If we are using the utility to triage an issue we typically find that an increase in the demand or offered load within the problematic dependency tends to easily correlate with the demand of the calling service. I think we are just at the beginning of leveraging this data in a more effective manner, and getting away from having eyeballs look at a dashboard is definitely a goal.