Hi Mark,
I am Prasant . I got your mail id from LR group. I have just started my career in Performance testing. I got a chance to work . LR . Currently I am working with LR 8.1. I have .e doubt regarding think time. While recoding .e . automatically think time got recorded in the .. While executing the . I am ignoring the think time. Is it required to ignore the think time or we have to consider the think time while executing the ..
I have questions in mind like, when think time is considerd as [time] the user is taking before giving input to the server . In that case while recording any . for a particular transaction I may take 50 seconds as think time and my friend who is recording the same . will take less than 50 seconds (let's say 20 seconds). So, in his . and in my . the think time will vary for same transaction. If I will execute both the .s considering the think time the transaction response time will vary . It may create confusion for the result analysis. Can you please give some of your view points about this.
Thanks,
Prasant
**********************************************
From: Tomlinson, Mark
Sent: Thursday, August 07, 2008 2:59 AM
To: Prasant
Subject: RE: Some questions about LR
Hi Prasant,
Yes – it is good that think time gets recorded, so the . will be able to replay exactly like the real application – with delays for when you are messing around in the UI. But you must be careful, if you are recording your . and you get interrupted…or perhaps you go to the bathroom, or take a phone call…you will see VERY LONG THINK TIMES getting recorded. You should keep track of this, and then manually go edit those long delays – make them shorter in the .. Make them more realistic, like a real end user.
Also, as a general rule of thumb you should try *not* to include think time statements in between your start and end transactions. You are right that it will skew the response time measurements. But for longer business processes where you have a wrapper transaction around many statements…it might be impossible to clean every transaction.
Here are 3 other tips for you:
First – in the run time settings, you have options to limit or adjust the think time settings for replay…you can set a maximum limit, or multiply the amount. The combinations are very flexible. You can also choose to ignore think times and run a stress test, although I typically will include even 1 second iteration pacing for most stress tests I run.
Second – you can write some advanced functions in the . to randomize the think times programmatically. This could be used to dynamically adjust the think time from a parameter value, in the middle of the test.
Third – even if you do have think times inside your start and end transactions, there is an option in the Analysis tool to include or exclude the think time overhead in the measurements displayed in the Analysis graphs and summary.
I hope you’ll find that with those 3 tips, you can get all the flexibility you need to adjust think times in your .s – try to make the most realistic load scenario you can.
Best wishes,
Mark
I am Prasant . I got your mail id from LR group. I have just started my career in Performance testing. I got a chance to work . LR . Currently I am working with LR 8.1. I have .e doubt regarding think time. While recoding .e . automatically think time got recorded in the .. While executing the . I am ignoring the think time. Is it required to ignore the think time or we have to consider the think time while executing the ..
I have questions in mind like, when think time is considerd as [time] the user is taking before giving input to the server . In that case while recording any . for a particular transaction I may take 50 seconds as think time and my friend who is recording the same . will take less than 50 seconds (let's say 20 seconds). So, in his . and in my . the think time will vary for same transaction. If I will execute both the .s considering the think time the transaction response time will vary . It may create confusion for the result analysis. Can you please give some of your view points about this.
Thanks,
Prasant
**********************************************
From: Tomlinson, Mark
Sent: Thursday, August 07, 2008 2:59 AM
To: Prasant
Subject: RE: Some questions about LR
Hi Prasant,
Yes – it is good that think time gets recorded, so the . will be able to replay exactly like the real application – with delays for when you are messing around in the UI. But you must be careful, if you are recording your . and you get interrupted…or perhaps you go to the bathroom, or take a phone call…you will see VERY LONG THINK TIMES getting recorded. You should keep track of this, and then manually go edit those long delays – make them shorter in the .. Make them more realistic, like a real end user.
Also, as a general rule of thumb you should try *not* to include think time statements in between your start and end transactions. You are right that it will skew the response time measurements. But for longer business processes where you have a wrapper transaction around many statements…it might be impossible to clean every transaction.
Here are 3 other tips for you:
First – in the run time settings, you have options to limit or adjust the think time settings for replay…you can set a maximum limit, or multiply the amount. The combinations are very flexible. You can also choose to ignore think times and run a stress test, although I typically will include even 1 second iteration pacing for most stress tests I run.
Second – you can write some advanced functions in the . to randomize the think times programmatically. This could be used to dynamically adjust the think time from a parameter value, in the middle of the test.
Third – even if you do have think times inside your start and end transactions, there is an option in the Analysis tool to include or exclude the think time overhead in the measurements displayed in the Analysis graphs and summary.
I hope you’ll find that with those 3 tips, you can get all the flexibility you need to adjust think times in your .s – try to make the most realistic load scenario you can.
Best wishes,
Mark
