Executive Summary
Before we proceed to discuss Performance Management in the world of Web 2.0 solutions, let us briefly examine where the core performance management disciplines evolved from. By doing so we can see that the fundamentals of Performance Management have not changed but in fact are required more than ever.
Read More
NOTE: This doesn’t generate a timestamp accurate to milliseconds. It just stores it in two fields. AFAIK there is no way to generate such a thing. It is accurately described here. Sorry for the confusion =)
Bug #8523 details MySQL’s deficiency in its ability to store and retrieve datetime values with millisecond or microsecond precision. When performance testing and perhaps storing trace logs or audit information in a MySQL table for later analysis, this shortfall is quite frustrating.
My hacky way to deal with this is to store the millisecond component as its own integer. Say for example you are interested in the difference between a Put datetime and Get datetime for MQ, your table might look like this:
CREATE TABLE `msecs` (
`put_datetime` datetime DEFAULT NULL,
`put_msecs` int(11) DEFAULT NULL,
`get_datetime` datetime DEFAULT NULL,
`get_msecs` int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
So in this table I am storing the datetime component in its native MySQL format and the millisecond component as an integer. Here are some examples:

Now to retrieve and compare the values, I get the difference using TIME_TO_SEC for the datetime component, multiply it by 1000 to convert to milliseconds then add to the difference of the milliseconds component using basic maths:
SELECT ((TIME_TO_SEC(get_datetime) - TIME_TO_SEC(put_datetime))*1000)
+ (get_msecs-put_msecs)
AS diff_msecs
FROM msecs
That gives you difference in milliseconds for the demo table along these lines:
2300
1700
300
600700
700
Hopefully that makes sense. Pipe up if you have an easier solution!
Read More
I’ve recently been playing around with AutoIt in an effort to steer clear of QTP and the like. AutoIt is a simple but effective way in which to automate pretty much any Windows GUI application. To that end I needed a simple data driven framework to include in the script. AutoIt comes with some handy Excel user defined functions which allow you to do the same.
For example, the following spreadsheet:

Can be read into an array and looped through as follows:
#include <excel.au3>
#include <array.au3>
$file = @ScriptDir & "\excel.xls"
$oExcel = _ExcelBookOpen($file, 0) ; open excel in the background
$aArray = _ExcelReadSheetToArray($oExcel, 2) ; ignoring header row
_ArrayDisplay($aArray, "Array using Default Parameters")
For $i = 1 to UBound($aArray)-1
$name = $aArray[$i][1]
$surname = $aArray[$i][2]
; do application stuff
MsgBox(0,'debug', $name &' '& $surname )
; write result to the book
_ExcelWriteCell($oExcel, "PASS", $i+1, 5)
Next
_ExcelBookClose($oExcel) ; close excel
Pretty simple stuff!
Read More
I recently had a conversation with a colleague about how one might determine the concurrency for a given page or transaction at any point in time. The system under test was a typical web server and we had access to the web logs for analysis.
That is, we wanted to know how many virtual users were hitting a web page at the same time without using a sledgehammer to open the walnut so to speak… To that end we fell back to simple unix commands like awk, sort and uniq.
The typical web log entry we were looking for looked like this:
10.1.20.10 - Unauth [16/Dec/2008:11:59:16 +1100] "GET HTTP://system.under.test/secure.html HTTP/1.1" 200 692
On windows we would use a command similar to this to generate our report:
gawk "{print $4,$7}" web01-request.log | grep "\/secure" | uniq -c | sort -T C:\temp | gawk "{print $1}" | uniq -c
The first awk prints the date time column and url column which we then grep for any entries containing our target word ‘secure’ (we could have done this in the awk statement too).
Then we use uniq -c to generate a unique count of rows that have the same date time, sort that (using a temp file), awk again on the first column and uniq -c again. The output looks like this:
2218 1
1483 2
263 3
258 4
38 5
36 6
2 7
5 8
1 12
So we can then determine for example that there were 1,483 occurrences where 2 virtual users hit the target at the same time. There were 258 occurrences where 4 virtual users hit the target at the same time and so on.
You can then graph this using the google chart API. No excel required =)

Read More
Confused about the subtle differences between a stress test, performance test or a load test? Don’t get lost in the technobabble! Altentee uses the following terminology to help describe the different types of tests we conduct:
- Shakeout – single script, single user, low volume scenarios whose main purpose is to confirm a correctly configured test harness (script, parameters, data, correlation, iterations) and environment.
- Baseline – arbitrary user/volumes (typically low with multiple iterations) used to establish a baseline or reference point for further testing. Can also be used to explore/set SLAs if they have not been defined by the business using minimum sample sizes appropriate to establish a baseline.
- Load / Volume – often expressed in terms of intended production load at 100% or variations of depending on the desired test outcome. Can also incorporate growth scenarios e.g. 200%. Can also be structured to incrementally increase and sustain load up to a target so that utilization metrics can be collected for capacity modelling at each increment (e.g. ramp up from 100 to 200 users at increments of 20 additional users, with sustained execution of 20 minutes at each increment).
- Stress / Stress to Break – loads greater than intended production loads or with the specific purpose to identify component failure or ‘break’ points. Other variants include Surge / Spike testing simulating peak demands over shorter timeframes.
- Soak / Endurance – long running tests to establish performance over longer timeframes and any anomalies over time.
- Failover / Availability – targeted tests under load in failover conditions. Can also be used to test disaster recovery or availability scenarios.
- Component Based – Targeted tests designed to isolate and examine components (functional and/or specific technologies/platforms) under load.
- Penetration / Security – with the increasing inclusion of security related non-functional requirements, targeted load tests which focus on application level and/or hardware level security NFRs.
- Tuning – cyclic / iterative performance testing using any number of variables in a process of test, tune, retest and compare (for improvement).
Still confused? Contact Altentee and we’ll help explain our approach.
Read More