Home > Performance, Performance Testing > Increasing Transaction Rate: a Valid Performance Testing Technique

Increasing Transaction Rate: a Valid Performance Testing Technique

Share

Just read a very good post Concurrency of Users Vs Increasing Transaction Rate by Jason Buksh about a pretty old question in load testing: if you could use less virtual users by increasing transaction rate.

Jason’s post discusses the subject in great details. One more thing worth mentioning is that the comparison between these two, say, approaches makes sense when the system handles the load well (low response times, etc.). As soon as the system starts to slow down, load becomes quite different (as far as you have a limited number of requests sent to the system with a small number of users).

Still I rather prefer to think about it not as about two equal approaches. If you use increasing transaction rate alone, it would be definitely cutting corners. Much better than nothing, but you still risk to miss issues related to high concurrency (which are quite probable).

I’d rather prefer to think about increasing transaction rate as an important performance testing technique to use in addition to using a realistic number users. This view is explained well in the Rapid Bottleneck Identification – A Better Way to do Load Testing white paper. Actually it was an Empirix white paper originally and there was a discussion about it back in 2005.

So increasing transaction rate leaves high concurrency risks and it is always better to test the full concurrency in the end. But increasing transaction rate may be a good technique to speedup performance testing and catch some issues earlier.

  1. March 14th, 2012 at 05:38 | #1

    Increasing the transaction rate is fine but does not take into account the variety of transaction types which flex different parts of a system – eg database updates.

  2. March 15th, 2012 at 09:01 | #2

    Why? You still may have different transaction types and increase their rates proportionally. It may be some minor rounding issues, but it doesn’t look like a major problem for me (comparing with other issues).

  3. March 22nd, 2012 at 23:24 | #3

    If increasing transaction rate implies and/or includes keeping lower think times or making it 0 then i do consider it useful as well as i was able to spot issues in various jdbc frameworks as well as xml library/parsing related concurrency issues typically in j2ee apps.

    Cheers
    Thx

Powered by Sweet Captcha
Verify your real existence,
Drag the smily to the T-shirt.
  • captcha
  • captcha
  • captcha
  • captcha