(This article was first published on

When it comes to assessing application scalability, controlled measurements of the type that can be obtained with tools like Grinder or LoadRunner, are very useful because they provide a direct measurement of the throughput, X(N), as a function of the vuser/generator load, N. These data can be input easily into my universal scalability model (USL). To apply USL, however, you need to normalize all the X(N) data to the X(1) value. It often happens that the X(1) value may not have been measured by your QA group or it simply may not be measurable easily. What do you do in that case? You **Taking the Pith Out of Performance**, and kindly contributed to R-bloggers)*estimate*it (carefully).

In Section 5.7.3 of my GCaP book, I explain how to use Excel to estimate X(1) from a fit to Amdahl's law. In that case, you only have to fit a

*single*modeling parameter, whereas the USL requires fitting

*two*modeling parameters. In the upcoming GDAT class, we will show you how to do this more accurately using nonlinear regression analysis based on iteratively minimizing the residuals (shown above) in both R and Mathematica. You really need to use these more sophisticated techniques to avoid numerical accuracy problems that might be lurking in Excel.

In setting up this discussion for the GDAT class, I ran into a frustrating problem with Mathematica. Here's the code from Jim's R script ...

R has a function called

`optimize()`which successively calls a user-defined function,

`function(x)`, with new trial values of X(1) until it determines the minimum value of

`sse/sst`(the ratio of the estimated sum-of-squares to the total) viz., the bottom of the curve shown above. The latter values are calculated using the

`nls`(nonlinear least-squares) library function in R with the USL model as its argument (the thing with the 'sigma' and 'lambda' in it; using my old notation). David Lilja will explain the role of SSE and SST in the first part of the class.

You can do exactly the same thing in Mathematica and here is my equivalent user-defined function:

Slight problem. The call-back didn't work! The argument

*trialX1*was not being evaluated, so the

**NonlinearRegress**function (the Mathematica equivalent of "nls") barfed. After a lot of debugging, I finally discovered the problem. Long story short: unlike R, Mathematica can also do

*symbolic computations*. In fact, that's its primary use (don't you wish you had it to evaluate those nasty integrals in your Calculus class?). Because of this "bias", it first tries to evaluate the argument

*trialX1*as a symbol, rather than a number. This behavior is correct but the justification is technical, so I won't go into that here. To disuade Mathematica from doing that, I needed to tell it explicitly to treat the argument as a numeric type and that's what the incantation

*trialX1_?NumericQ*does. Simple, when you know!

Once again, this proves what I've said on many occasions: All modeling is programming and all programming is debugging.

To

**leave a comment**for the author, please follow the link and comment on his blog:**Taking the Pith Out of Performance**.R-bloggers.com offers

**daily e-mail updates**about R news and tutorials on topics such as: visualization (ggplot2, Boxplots, maps, animation), programming (RStudio, Sweave, LaTeX, SQL, Eclipse, git, hadoop, Web Scraping) statistics (regression, PCA, time series, trading) and more...