## User Tag List

Thanks:  0
Likes:  0
Dislikes:  0

Previously I got information on load modeling from this forum (The text is below)

My question is how do you handle think times with reference to the load model. Our production is showing average session duration being 2 minutes which means whatever iteration a user is completing, they are remaining logged in for at least 2 minutes while completing the iteration.

THe Load Modeling 101 information below only handles mean time between iterations or iteration pacing.

What happens when iterations have a need to be slowed up by think times to satisfy session duration requirements??
This turns into quite a difficult math problem.
Anyone know an easier way to tackle this.

 900 orders
 150 users
 6 orders per user per hour
 600 seconds, mean time between iterations (3600/6)
 480 - 720 seconds spread time between iterations (20%+/-). Random distribution is approx uniform in LoadRunner. Average should equal ~ 600 seconds between iterations
 1/3 time under full load = ramp up
 1 hour time under full load
 1 hour + .333 ramp up or amt of time under full load + .333 (formula for calculating next bullet. (not sure))
 1.3333 * 6 (iterations per hour) = iterations per user including ramp up/down
 Ramp up users over 1/3 hour (1200) seconds. Approx 1 user every 8 seconds. (1200/150 = 8) Run until iterations are exhausted. As iterations exhaust, vusers should die off naturally without having to be forced to ramp down.

600 seconds = 10 minutes

Your average session duration is 2 minutes.

Even with a variation of +/- 20% (8-12 minute range), you should be able to finish your iteration in plenty of time before the next iteration.

If your application business process and/or user cannot complete the business process within the guidelines set forth to meet your production goals (volume requirements), then you have a failure in the design stage (too many steps/too complex) or in the implementation stage (app/codebase too slow). Either way it is a failure to meet your business requirements for volume.

Perhaps I have had a misunderstanding of the load model to a small extent in the first place. I thought that [ 600 seconds, mean time between iterations (3600/6) ]
was interpreted as saying there was 600 secs/10 min. between iteration starts. Meaning once an iteration finishes in his natural amount of time like 40 seconds for example then the vuser would not start another iteration for 600 secs/10 min.

However it appears that what you are saying is that 600 secs/10 min. is the length of the iteration. The extra seconds are in between transactions that are set in the iteration.
I hope this is a better understanding for me. If so then this load model is awesome and problem already solved.

The way I've tried to implement this is by using iteration pacing in loadrunner's run time settings. When I use iteration pacing and set it to 600 secs or a plus minus 20% over/under, it's making a vuser iteration last 600 secs on average and placing think times in between transactions automatically for me. If this is the proper interpretation then this is great.

This is clearly different than looking at iteration pacing as wait or idle time between completed iterations. Please clarify that I was on the wrong track and now better understand.

Thanks a lot
HollisB

You have the choice of iteration pacing based on end-to-start or start-to-start. It's right there in the group pacing setup.

Let me take a look at LR 8.0's group pacing setup in Run-Time settings again.
I'm not following what you mentioned.

I am not clear on my question after James Pulley's response still.
I looked at Run Time settings and the definition of the choices it has supports my original way of thinking. (Iteration pacing being idle/wait time between iteration starts and iteration ends.

Start iteration at predefined interval:

Sets a fixed or random interval between the beginning of iterations: New iterations will not begin until the previous iteration has completed, even if it surpasses the interval time. FOr a fixed interval, specify the number of seconds. For a random interval, specify a range from which the Vuser chooses random values.

Start iteration after the previous iteration ends, Sets a fixed or random delay after the completion of each iteration. If you choose fixed, specify the fixed number of seconds between iterations.
For random, specify a range of seconds from which the Vuser chooses random values.

This reads pretty straight forward. Am I searching in the wrong place?

Sets a fixed or random interval between the beginning of iterations
<font size="2" face="Verdana, Arial, Helvetica">It means start to start, not end to start.

And I think it's probably what you want.

Quote--
The way I've tried to implement this is by using iteration pacing in loadrunner's run time settings. When I use iteration pacing and set it to 600 secs or a plus minus 20% over/under, it's making a vuser iteration last 600 secs on average and placing think times in between transactions automatically for me. If this is the proper interpretation then this is great.---------

This is not propper interpretation...
1) LR will not add think time automatically between the transactions
2)Iteration pacing only adds delay between the iterations. it does not do any think with think time or overall duration or lasting of iteration as you have mentioned

Refer VUGen manuals on iteration pacing

With this last comment being said as the following:
1) LR will not add think time automatically between the transactions
2)Iteration pacing only adds delay between the iterations. it does not do any think with think time or overall duration or lasting of iteration as you have mentioned

I agree and this says that the Load Modeling 101 information does not address trying to simulate in a load test environment the average session duration based on what a project team might have researched in their own production environment.

What I found from running a test was when I ran at a low workload level, the transactions were clumped together in a group and then the next clumped group started running after a delay based on iteration pacing. So the session duration was not effected at all. There was no think times between transactions based on setting iteration pacing.

The result left a need for more load modeling information beyond load modeling 101.

The last comments and my findings from running a test shows the need for think time additions based on session duration goals.

Your terminology is throwing me. Think time BETWEEN iterations is meaningless. "Think time" is a LoadRunner term describing specified delays WITHIN an action.

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•
Search Engine Optimisation provided by DragonByte SEO v2.0.36 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.