On Realistic Wait Times

Simulating a realistic user is an important part of test script design. Your user actions might seem atomic and stateless at first glance but the pauses between certain steps as well as a total duration of your user session leave a distinct footprint in your application you can’t really replicate without letting your Vuser take a break.

The No. 1 issue you’re most likely to find is the memory saturation. If your users stay logged in for a longer time, your app needs to retain the session context in its memory to make sure you stay logged in – it also may cache some data for your convenience, so the memory consumption grows and it usually stays there until you log out.

No. 2 problem you might come across is the locking. My favourite example is reserving a seat in a cinema. It requires acquiring a semaphore to make sure the application won’t let people reserve more seats than there available at the moment, and after that, a user acquires another lock to make sure no one else takes particular seats at the same time. If these locks wouldn’t be acquired for long enough – your report would probably never show how long waiting times would be for your users. A more extreme example of a lock would be a deadlock, where two users would attempt to acquire two locks in a tight grip. The only remedy to make them let go really is an application restart.

No 3 is your reporting capability because you can measure and report how many users your application can take at once, and it will be in line with business expectations.