I’ve just come back to the OSX fraternity after a spell away on Ubuntu. I love Linux and I really miss some of the awesome tools like pssh that are available. There’s an awesome post on keeping things “outside the bun” where “you can achieve the desired functionality simply with clever reconfigurations of the basic Unix tool set. After all, functionality is an asset, but code is a liability.”

So here’s my attempt to roll two useful pssh tools (parallel-ssh and parallel-scp) into reusable scripts with our old friend xargs.

Often when performance testing in a black box environment, you are left with the onerous responsibility to report against response time performance.

A typical approach by performance testers is to rely on 95th percentiles, which is effectively a Service Level Agreement (SLA) saying that 95 percent of all my samples have a response time below 5 seconds. This is often specified as a Non Functional Requirement (NFR).

But so what? What does this really tell us? More importantly, if the SLA fails, you’re probably left hanging in the wind trying to explain how “bad” it failed to a (now interested) Project Manager. On the flip side, if everything is green, how close were you to failing? Are you an n’th degree away from failing? What about comparing two different application’s response time performance when they have different NFRs to begin with? Getting confused?

Enter the Apdex performance index. Apdex is a numerical measure of user satisfaction that can be built from metrics expressed via more traditional SLAs and/or NFRs. The fundamental objective of Apdex is to simplify the reporting of application response time measurements by making it possible to represent any such measurement using a common metric. This can be reported on by extracting data from Load Runner / JMeter and analysing within Excel as demonstrated below.

Read on to find out more about these scores and how they are calculated.