You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Philippe Bossu <pb...@gmail.com> on 2012/11/02 16:15:50 UTC
Computing number of VU
Hello,
I have to load test a website that has a number of visits per days and a
visit duration.
What is the formula to compute the number of Virtual Users (Threads) that I
need to put in my tests.
I read that this number can be computed using 2 different informations:
- Method1 => Peak visit rate (visits/hour) and Average visit length
(minutes/visit), it would then be => visitRate/(60/visitLength)
- Method 2 => Peak page rate (pages/hour), Testcase size (number of
pages seen by User) and Testcase duration (in minutes),it would then be
=> (Peak page rate*testcaseDuration)/(60*testcaseSize)
My question is with method 1, must my test Iteration last the "average
visit length" using Timers and what more to make it last that length ?
My question with method 2, are we talking about my Test Plan duration ?
Which method is the best one ?
Thank you
Regards
Re: Computing number of VU
Posted by Deepak Goel <de...@gmail.com>.
Average is the norm, peak the exception :) Depends on functionality also
On 11/2/12, Adrian Speteanu <as...@gmail.com> wrote:
> Hi,
>
> I can't decide between 1 or 2. IMO, they are not exclusive of each other,
> they should be used in combination:
>
> What I do:
> -1- have a clear breakdown of real-life traffic (or estimated traffic):
> that many requests of each type (numbers, network traffic fluctuations,
> frequency of requests and so on...)
> -2- have a clear breakdown of number of users
> -3- create a test script that reaches targets from #1 at the scale of
> the test setup (which is not always as big as the production setup)
> -4- fine tune the script until the number of active/inactive user
> sessions (server side) coincides with production target...
> --------------------------
> Reasoning:
> Yeah, its nice to know user session length and actual behaviour. But in
> practice, due to a desire to protect your users' privacy or due to lack of
> data, you only have a clue of what you actually need, but not a real grasp
> of the numbers you need. More, often you do have the big numbers and the
> detailed use-cases actually come from marketing/sales/client side - and the
> second, I strongly recommend to "use with caution", consult them, but don't
> trust them. In the end, the impact on the server-side, will be the same if
> you make your homework correctly... IMO, with this method you cover
> edge-cases too: the average user session might not have that request that
> takes only 1% of the total traffic, but that request might be good to have
> in the load test plan.
>
> When lacking good statistics or when you have a new application with no
> data from existing live environments, then you should simply push the
> system to the limit, gradually, until performance would be unacceptable to
> you and/or end-users.
> ----------------------------
> Other:
> Last, but not least, you should NOT focus solely on simulating VUs. I still
> see this trend of mistrusting synthetic benchmarks and is ridiculous. Yes,
> some tests do not reflect how the end-user will perceive performance, BUT
> those kind of tests: 1) give better understanding to the dev team of what
> the problem is, performance wise - which obviously is needed in order to
> FIX IT; 2) can be used to monitor performance fluctuation of specific
> functionalities and this can be monitored over time, with multiple app
> versions; 3) they make it easier for you, the tester, to understand the
> application architecture and performance particularities which are actually
> essential in order to create a realistic test that tries to simulate VUs...
> so start with this, end with what you had in mind before you sent the
> email.
>
> Cheers,
> Adrian S
>
>
> On Fri, Nov 2, 2012 at 5:15 PM, Philippe Bossu <pb...@gmail.com> wrote:
>
>> Hello,
>>
>> I have to load test a website that has a number of visits per days and a
>> visit duration.
>>
>> What is the formula to compute the number of Virtual Users (Threads) that
>> I
>> need to put in my tests.
>>
>> I read that this number can be computed using 2 different informations:
>>
>> - Method1 => Peak visit rate (visits/hour) and Average visit length
>> (minutes/visit), it would then be => visitRate/(60/visitLength)
>>
>>
>> - Method 2 => Peak page rate (pages/hour), Testcase size (number of
>> pages seen by User) and Testcase duration (in minutes),it would then
>> be
>> => (Peak page rate*testcaseDuration)/(60*testcaseSize)
>>
>>
>>
>>
>> My question is with method 1, must my test Iteration last the "average
>> visit length" using Timers and what more to make it last that length ?
>>
>>
>> My question with method 2, are we talking about my Test Plan duration ?
>>
>>
>> Which method is the best one ?
>>
>>
>> Thank you
>>
>> Regards
>>
>
--
Namaskara~Nalama~Guten Tag~Bonjour
--
Keigu
Deepak
+91-9765089593
deicool@gmail.com
http://www.simtree.net
Skype: thumsupdeicool
Google talk: deicool
Blog: http://loveandfearless.wordpress.com
Facebook: http://www.facebook.com/deicool
"Contribute to the world, environment and more : http://www.gridrepublic.org
"
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: Computing number of VU
Posted by Adrian Speteanu <as...@gmail.com>.
Hi,
I can't decide between 1 or 2. IMO, they are not exclusive of each other,
they should be used in combination:
What I do:
-1- have a clear breakdown of real-life traffic (or estimated traffic):
that many requests of each type (numbers, network traffic fluctuations,
frequency of requests and so on...)
-2- have a clear breakdown of number of users
-3- create a test script that reaches targets from #1 at the scale of
the test setup (which is not always as big as the production setup)
-4- fine tune the script until the number of active/inactive user
sessions (server side) coincides with production target...
--------------------------
Reasoning:
Yeah, its nice to know user session length and actual behaviour. But in
practice, due to a desire to protect your users' privacy or due to lack of
data, you only have a clue of what you actually need, but not a real grasp
of the numbers you need. More, often you do have the big numbers and the
detailed use-cases actually come from marketing/sales/client side - and the
second, I strongly recommend to "use with caution", consult them, but don't
trust them. In the end, the impact on the server-side, will be the same if
you make your homework correctly... IMO, with this method you cover
edge-cases too: the average user session might not have that request that
takes only 1% of the total traffic, but that request might be good to have
in the load test plan.
When lacking good statistics or when you have a new application with no
data from existing live environments, then you should simply push the
system to the limit, gradually, until performance would be unacceptable to
you and/or end-users.
----------------------------
Other:
Last, but not least, you should NOT focus solely on simulating VUs. I still
see this trend of mistrusting synthetic benchmarks and is ridiculous. Yes,
some tests do not reflect how the end-user will perceive performance, BUT
those kind of tests: 1) give better understanding to the dev team of what
the problem is, performance wise - which obviously is needed in order to
FIX IT; 2) can be used to monitor performance fluctuation of specific
functionalities and this can be monitored over time, with multiple app
versions; 3) they make it easier for you, the tester, to understand the
application architecture and performance particularities which are actually
essential in order to create a realistic test that tries to simulate VUs...
so start with this, end with what you had in mind before you sent the email.
Cheers,
Adrian S
On Fri, Nov 2, 2012 at 5:15 PM, Philippe Bossu <pb...@gmail.com> wrote:
> Hello,
>
> I have to load test a website that has a number of visits per days and a
> visit duration.
>
> What is the formula to compute the number of Virtual Users (Threads) that I
> need to put in my tests.
>
> I read that this number can be computed using 2 different informations:
>
> - Method1 => Peak visit rate (visits/hour) and Average visit length
> (minutes/visit), it would then be => visitRate/(60/visitLength)
>
>
> - Method 2 => Peak page rate (pages/hour), Testcase size (number of
> pages seen by User) and Testcase duration (in minutes),it would then be
> => (Peak page rate*testcaseDuration)/(60*testcaseSize)
>
>
>
>
> My question is with method 1, must my test Iteration last the "average
> visit length" using Timers and what more to make it last that length ?
>
>
> My question with method 2, are we talking about my Test Plan duration ?
>
>
> Which method is the best one ?
>
>
> Thank you
>
> Regards
>