THINK TIME – Part 1

According to VuGen Document think time is "The time that a user waits between performing successive actions is known as the think time."
 Think time is the time spent by a user perusing a Web page, including viewing the page and determining the next action. Think time does not include the time that is required for a page to load.
 Why think time is important?
Answer will be Think time makes our scripts more realistic.

But why does think time matter?If I have a simple script that logs into an application, performs some actions like check account balance, Transfer amount ..etc and then logs out, why do I care if it pauses in-between page requests?

Actually, Think time matters because it holds the current user's session for a realistic period of time. This means the memory footprint of that user exists for longer (compared to not using or ignoring think time) and as a consequence we can be more confident that our scripts/test is providing a useful representation of how memory will be used in the JVM.With think time we can test concurrency. If there is no accurate concurrency we cannot test heap size, garbage collection, thread / connection pool sizes, etc., and our entire load test would pretty much be wrong and our test substantially is less useful.

So, does this mean, in every type of test we should include Think time?

Answer is NO. If we are writing a script to test calls to atomic webservices then we need not use artificial wait times. The requests will still be using memory in the application server but, in the case of a stateless, atomic call, this memory will only exist for the life of the actual request and the inclusion of think time in-between each call will serve no purpose and could actually detract from the benefit of the test. Also, omitting think time can be helpful when you want to generate excessive load on the server. We will come to this point in a while.

Always, make sure that the think time in test scripts is based on real life conditions. This varies according to the operations performed by the user, and it varies depending on the page the user is interacting with.
For our test scripts, we can program for either a fixed think time between consecutive requests or a random think time ranging between minimum and maximum values.

In LoadRunner using web(HTTP/HTML) protocol:

During the recording using VuGen, we maybe entering values into the text fields, or browsing through the data sheet or maybe thinking of something (whatever…), all these will be recorded and generate as a LoadRunner API, lr_think_time. Think time is as recorded during the recording of the application.

How to change the value for Think Time:

In Script-view, for example we should see it as lr_think_time(120) if you had used 120secs to perform a task such as entering values into a form. To change the value, simply change the value in lr_think_time(120) to lr_think_time(60) which means you are changing the value from 120secs to 60secs. This is the same in the Tree-view also.

You can further manipulate how the Think Time will be replayed in the Run-Time Settings.

 

Below are think time options in LoadRunner :

 

Ignore think time:

Think times are ignored. The script is going to run without any delay between each transaction. Use this setting when you want to generate maximum load to heavily stress your Web server. Do not use it when you are trying to create more realistic user interactions with a Web server.

 

Replay think time:

Think times are used exactly as they were recorded in the Web performance test. Simulates multiple users running the Web performance tests exactly as recorded. It looks all good in Vugen at first but when you are in the Controller, it looks weird as all vusers will be replaying at the same amount of think time. If you have transactions created for the script, in the Controller graphs, all transactions will perform at the same speed. Because a load test simulates multiple users, using the same think time could create an unnatural load pattern of synchronized virtual users.

 
Multiply Recorded think time by:
This setting multiplies the recorded value with the numeral provided, extending the time delay in the script. Can increase or decrease the think time as recorded. Means we can increase the think time by multiplying the recorded think time with 1,2 or to decrease the think time multiply the recorded think time with 0.5 or so. The range of value we can enter is 0.01 to 10000.

 
Use random percentage of recorded think time:

The script will replay the percentage range of the recorded think time. With the recorded think time, we can allow 50% – 150% deviation emulating the expert users (lower range:50%) and novice users (upper range:150%) assuming the speed we are working (recording) with the application is at an average user speed. Provides a more realistic simulation of virtual users by slightly varying the think time between requests.

 
Limit think time to:
This last option allows the script to replay the maximum think time limit. Suppose while recording or using the above two options we have different think times in different transactions like 60, 90, 120 etc. If we select the option Limit think time to 40 seconds. The think time allowed will be only 40 seconds. If the think time is more, the remaining time is ignored and if it is less it will as it is.