Average is the norm, peak the exception :) Depends on functionality also On 11/2/12, Adrian Speteanu <[email protected]> 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 <[email protected]> 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 [email protected] 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: [email protected] For additional commands, e-mail: [email protected]
