This question on linked in:
http://www.linkedin.com/answers/technol ... 81-3692291
... reminded me that I must spend *a lot* more time digging into the monitoring environments.

I was speaking last week with an Oracle DBA doing battle with a problematic 4.5 hour batch process. He had some great ideas on monitoring the performance of his process. The work is on going, but we were talking about getting his custom monitoring output shared through a standard format such as linux RSTATD.

This way the process can be monitored in the live environment if required. Of course I was thinking about getting the data across into LoadRunner Analysis.

People don't spend nearly enough time considering the monitoring requirements for performance testing.

I was recently helping a colleague to highlight how good some transaction response times were. However his graphs were plagued with the odd "spike" where a response time was really bad, i.e from 1.4 seconds average up to a 90+ second spike.

This made the transaction response time graph look bad and would have cause the reader of the report to focus on the spikes instead of the averages.

Instead a transaction response time distribution graph was used, this highlights a count just how many transaction had a particular response time:



The graph is much easier to talk about since the readers ear is immediately (and rightly so) drawn to the the "big number".

What I'm wondering about now is - why are there two clear groups of slow transactions? Between 46 to 58 seconds and 76 to 98 seconds. I've heard about defect clustering - but slow transaction clustering sounds strange.... but they are clustered.

I managed to get an article published on LoadRunnerTnT.com :-)

http://loadrunnertnt.com/articles/34-co ... ure-places

One of my colleauges is always using Mind Maps to take notes and during brainstorming sessions.

Currently I'm working on a large bid response which has a Performance Testing element. There are masses of documentation and performance information scattered through - so I tried to Mind Map the problem in order to look at the area I'm responsible for.

I downloaded FreeMap from here: http://freemind.sourceforge.net/wiki/in ... /Main_Page

Then I produced this Mind Map:


I've not "solved" the problem, or rather fully understood it - but it makes for a really useful brain dump of the problem space :-)

I just had an 8 hour stress test reduced to 2.5 hours because someone forgot to turn off some overnight batch jobs on Friday... great :-(

I've not used Global Filters before in LoadRunner Analysis (File > Set Global Filter...) but using this I can limit the results to just the first 2.5 hours of the test... I.e. before the batch jobs kicked in.

Not an ideal situation and certainly not a stress test, but at least I have "some" results from Friday.



You can filter on all sorts of values, I've seen some Performance Testers make use of dynamic transaction names in order to analyse response times from a certain reason. Before doing that you should look at what is acheivable via filters.