C(N) = 
N


I have yet to see an equation expressing response time as a function of throughput. I believe this is fundamentally wrong  it is not actually a function. The reverse is true instead: throughput can be expressed as a function of latency.
Here's some real data from a system, charted as usual for the USL, with throughput as a function of concurrency/load (threads, in this case)Notice that this system has gone past the inflection point of Nmax and is in retrograde scalability. Now using Little's Law, plot latency as a function of throughput.
Oops. That ain't a function.
If you disagree, please show me the equation you arrive at if you use Little's Law to solve the USL for response time as a function of throughput.Of course this is just as easy to demonstrate with the USL itself instead of benchmark data, but there's been a bunch of discussion about how "think time" changes things somehow. I don't agree with that. Little's Law is Little's Law. I can measure this stuff directly in the field, and my empirical observations agree exactly with the results I compute from Little's Law.Here is what I believe is the correct relationship: throughput as a function of latency.I haven't taken the time to rearrange the USL to find the equation for this but I intend to at some point... algebra is my weak point.
Oops. That ain't a function.Whaddya mean, it's not a function?
Oops. That ain't a function.Whaddya mean, it's not a function?It's a function,
but not of the value represented on the horizontal axis. A single tputvalue can produce multiple latencyvalues.
The horizontal axis is showing the dependent variable in this plot.
The horizontal axis is showing the dependent variable in this plot.As you've plotted it, the throughput is the independent variable.
You're making my point for me. We're in agreement. X is a function of N, not the inverse

You received this message because you are subscribed to the Google Groups "Guerrilla Capacity Planning" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guerrillacapacity...@googlegroups.com.
To post to this group, send email to guerrillacap...@googlegroups.com.
Visit this group at http://groups.google.com/group/guerrillacapacityplanning.
For more options, visit https://groups.google.com/d/optout.
Not being pedantic, and just speaking in generalities: the throughput is identical and the concurrency is higher, so the latency (residence time) must be higher. The service time can be assumed to remain constant. Therefore the queue length and the queue wait time is higher at N=32 than at N=25.
It seems like this is a case of offered load (N) vs. active load (XR).Above 25 any extra load is queued hence not contributing to increased throughput and this queueing causes increased response time, when measured from the system offering the load.
To unsubscribe from this group and stop receiving emails from it, send an email to guerrillacapacityplanning+unsub...@googlegroups.com.
To post to this group, send email to guerrillacapacityplanning@googlegroups.com.
Alex. Hopefully, my more remarks above will also provide you with an explanation.
On Wednesday, October 28, 2015 at 8:23:08 PM UTC7, ceeaspb wrote:
It seems like this is a case of offered load (N) vs. active load (XR).Above 25 any extra load is queued hence not contributing to increased throughput and this queueing causes increased response time, when measured from the system offering the load.
To unsubscribe from this group and stop receiving emails from it, send an email to guerrillacapacity...@googlegroups.com.
To post to this group, send email to guerrillacap...@googlegroups.com.
Visit this group at http://groups.google.com/group/guerrillacapacityplanning.
For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups "Guerrilla Capacity Planning" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guerrillacapacity...@googlegroups.com.
To post to this group, send email to guerrillacap...@googlegroups.com.

Interesting thanks.
Looks Similar to the section in Perl PDQ "Adding overdriven throughput in PDQ".
On Thursday, October 29, 2015, 'DrQ' via Guerrilla Capacity Planning <guerrillacapacityplanning@googlegroups.com> wrote:
Alex. Hopefully, my more remarks above will also provide you with an explanation.
On Wednesday, October 28, 2015 at 8:23:08 PM UTC7, ceeaspb wrote:
It seems like this is a case of offered load (N) vs. active load (XR).Above 25 any extra load is queued hence not contributing to increased throughput and this queueing causes increased response time, when measured from the system offering the load.
To unsubscribe from this group and stop receiving emails from it, send an email to guerrillacapacityplanning+unsub...@googlegroups.com.
To post to this group, send email to guerrillacapacityplanning@googlegroups.com.
Visit this group at http://groups.google.com/group/guerrillacapacityplanning.
For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups "Guerrilla Capacity Planning" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guerrillacapacityplanning+unsub...@googlegroups.com.
To post to this group, send email to guerrillacapacityplanning@googlegroups.com.
Here's an XR plot of response time "as a function of" throughput using that table of data.Please refer to my previous comments. It's not a hockey stick. It's not even "lifted away from the hockey stick." It is lifted away, then folded back on itself (i.e. clearly not a function of the variable on the horizontal axis). I am in full agreement with many of your remarks.Excellent. I think we're almost there. All these plots look correct now. The 'hockeystick' metaphor applies only to the R v N plot, since only it has the diagonal asymptote. The 'nose' metaphor only applies to the R v X plot. That's exactly what you have.

You received this message because you are subscribed to the Google Groups "Guerrilla Capacity Planning" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guerrillacapacity...@googlegroups.com.
To post to this group, send email to guerrillacap...@googlegroups.com.

You received this message because you are subscribed to the Google Groups "Guerrilla Capacity Planning" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guerrillacapacity...@googlegroups.com.
To post to this group, send email to guerrillacap...@googlegroups.com.
Visit this group at http://groups.google.com/group/guerrillacapacityplanning.
For more options, visit https://groups.google.com/d/optout.
 David CollierBrown,  Always do right. This will gratify System Programmer and Author  some people and astonish the rest dav...@spamcop.net   Mark Twain