Explanation

The transaction result model is a representation of the aggregated values for a single test or transaction.

The view at bottom of the console window is a list of transaction result models.

They summarise the following information:

• Test name
• Transaction name, where relevant
• The SLA, if configured
• The total transaction count
• The target transaction's per second (effectively agents * threads * target rate)
• A 5 second moving average of the total successful transactions per second
• A 5 second moving average of the mean duration of the successful transactions
• The 90th percentile duration of the successful transactions - this is based on a moving window, configured using maximumResultsPerKey
• The standard deviation (population - although this doesn't sound like the right choice) of the successful transactions - based on the same moving window of successful results
• The time-in-test - this is a 5 second moving average of the mean duration each test/transaction spent executing beforeIteration, runIteration and afterIteration. This is useful as it provides the data for the next bit...
• The theoretical maximum success rate (ceiling rate) of the test for a single thread - 1000/time-in-test - effectively gives us the maximum rate you'll be able to drive a single thread through your test. This is very important when it comes to working out your next bottleneck - you'll never be able to fire data at your system faster than this value on a single thread.
• A ChartLineFormat that provides the information used to recognise this test/transactions plot on the charts
• A list of ChartEvents that provide details about overlay information to be displayed on the plot for this test
• The total count of unsuccessful transactions
• The threshold for the total count of unsuccessful transactions that will force the test to abort
• The threshold for the mean successful transaction duration that will force the test to abort
• An enumeration that controls the comparison operation (mean, stddev, tp90) to use for successful transaction duration abort checking
• The minimum number of transactions we need to have processed before applying the successful transaction duration abort check

Implementation

The TransactionResultModel should be a dumb-model object, using the com.logginghub.utils.Observable framework. It should be updated by a controller - maybe the ResultsController - when:

• A new result bucket becomes available - ie all agents have posted a result that second which can be aggregated. The tp90 and stddev can be updated by posting the latest results to the moving window and recalculating.

Standardised naming

There are so many different terms used in the code for roughly the same values. Here is an attempt to start standardising:

• successfulTransactionCount - any total/sum/count of successful transactions
• unsuccessfulTransactionCount - any total/sum/count of unsuccessful (aka failed) transactions
• successfulTransactionDuration - any mean successful transaction duration
• unsuccessfulTransactionDuration - any mean unsuccessful transaction duration
• successfulTransactionTotalDuration - any mean successful transaction duration including the full time-in-test

Durations are always stored in nanoseconds by default. Provide accessors for milliseconds where appropriate.

They have counterparts when dealing with per-second aggregations

• successfulTransactionsPerSecond - any mean of successful transactions averaged over a second
• unsuccessfulTransactionPerSecond - any mean of unsuccessful (aka failed) transactions averaged over a second