On Fri, Mar 5, 2010 at 4:11 PM, Deepak Goel <[email protected]> wrote:
> Bret > > The method which should work is as follows: > > Method > Rampup period is independent of loops. The rampup period is present to > increase the number of threads. Once the threads are started they keep on > executing the loops only depending on the think time. > Ah - I understand, the loop is applied to the thread. I thought the loop was applied to the threadgroup. So an infinite loop would mean each thread continues to loop, and i can increase the number of threads over time. Thanks for the explanation Deepak. > > Deepak > > On Fri, Mar 5, 2010 at 7:36 PM, Brett Cave <[email protected]> wrote: > > > On Fri, Mar 5, 2010 at 4:00 PM, Deepak Goel <[email protected]> wrote: > > > > > Bret > > > > > > Why should the threads come to end end before the next loop enters? > They > > > should remain and keep on executing the next loops. Once the rampup > > period > > > has reached, the threads should remain constant executing the next > loops. > > > > > > > I thought this would be 1 of 2 methods for determining when to loop. > > > > Method 1. > > Wait for all threads to end and then start next loop > > > > Method 2. > > Wait until rampup period has expired and then start next loop. > > > > > > or is another method used? > > > > > > > Deepak > > > > > > On Fri, Mar 5, 2010 at 7:14 PM, Brett Cave <[email protected]> > wrote: > > > > > > > On Tue, Mar 2, 2010 at 3:36 PM, Deepak Goel <[email protected]> > wrote: > > > > > > > > > Hey Bret > > > > > > > > > > You might like to give a very large number in the number of loops > > > instead > > > > > of > > > > > 1. That will ensure that all the threads are running concurrently > at > > > the > > > > > end > > > > > of the test. > > > > > > > > > > > > > For each loop, do all running threads come to an end before the next > > loop > > > > enters, or does the next batch of threads get started up once the > > rampup > > > > period has been reached? > > > > > > > > > > > > > Regards > > > > > Deepak > > > > > > > > > > On Tue, Mar 2, 2010 at 5:15 PM, Brett Cave <[email protected]> > > > wrote: > > > > > > > > > > > On 3/2/10, Deepak Goel <[email protected]> wrote: > > > > > > > Hey Bret > > > > > > > > > > > > > > How many page request have you given as input? > > > > > > > > > > > > > > Can you also please post the results in terms of number of > > > > request/sec > > > > > > > (Throughput) instead of total number of samples per page > (request > > > per > > > > > > item)? > > > > > > > (Jmeter still might be increasing the number of threads at the > > rate > > > > of > > > > > > 1.6 > > > > > > > per minute) > > > > > > > > > > > > Hi Deepak, > > > > > > > > > > > > I have checked out the source, it seems that this is not how the > > > > > > ramp-up feature works. It works as follows: > > > > > > > > > > > > startDelay = ramp-up time / number of threads. > > > > > > each thread is then started with threadNumber x startDelay set as > > its > > > > > > start delay. > > > > > > > > > > > > For example, if 100 threads are configured for 600 seconds, then > > > start > > > > > > delay is 6. > > > > > > All 100 threads will be initialized up front. The first thread > will > > > > > > have a start delay of 0, the 2nd will start after 6 seconds, then > > 3rd > > > > > > after 12s, 4th after 18s and so on. > > > > > > > > > > > > This means that ramp-up threads is not an indication of the final > > > > > > concurrent threads that will be run during the test plan, but > > rather > > > > > > the total number of threads to run during the test plan. > > > > > > > > > > > > Obviously, working the maths backwards doesnt work well, as to > test > > > > > > specific levels of concurrency you need to know how long each > > thread > > > > > > would last. There is also no limit of how many concurrent threads > > are > > > > > > running at any time. > > > > > > > > > > > > I am working on a patch that would allow a more logical approach > to > > > > > > testing, where a flag can be set to indicate that the ramp-up > > threads > > > > > > is a "final concurrent # of threads" rather than "total # of > > threads" > > > > > > metric. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > Deepak > > > > > > > > > > > > > > On Tue, Mar 2, 2010 at 12:54 PM, Brett Cave < > [email protected] > > > > > > > > wrote: > > > > > > > > > > > > > >> Hi all, > > > > > > >> > > > > > > >> I have a test plan that I use to increase the load on a target > > > > system. > > > > > > >> There > > > > > > >> is 1 thread group, configured as follows: > > > > > > >> Threads: 200 > > > > > > >> Ramp-up Period: 7200 > > > > > > >> Loop count: 1 > > > > > > >> > > > > > > >> To my understanding, this should increase the number of > threads > > > over > > > > 2 > > > > > > >> hours > > > > > > >> from 1 to 200 (about 1.6 more threads per minute). > > > > > > >> > > > > > > >> The test runs non-interactively and logs to a file. If I check > > the > > > > > logs > > > > > > >> after the test, I see a total # of samples per page (requests > > per > > > > > item) > > > > > > of > > > > > > >> 100. I think my understanding of the ramp-up mode is incorrect > - > > > > > should > > > > > > >> JMeter not start with 2 threads, then increase upwards until > 200 > > > > > threads > > > > > > >> are > > > > > > >> running at the end of the period? (i.e. 100 threads after 1 > > hour). > > > > > This > > > > > > >> should also result in a lot more samples that what I am > getting. > > > > > > >> > > > > > > >> Regards, > > > > > > >> Brett > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Guten Tag > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Keigu > > > > > > > > > > > > > > Deepak > > > > > > > +91-9765089593 > > > > > > > [email protected] > > > > > > > > > > > > > > Skype: thumsupdeicool > > > > > > > Google talk: deicool > > > > > > > Blog: http://loveandfearless.wordpress.com > > > > > > > > > > > > > > Check out my Work at: > > > > > > > LinkedIn: http://in.linkedin.com/in/thumsupdeicool > > > > > > > > > > > > > > "Contribute to the world, environment and more : > > > > > > http://www.gridrepublic.org > > > > > > > " > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: > [email protected] > > > > > > For additional commands, e-mail: > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Guten Tag > > > > > > > > > > > > > > > -- > > > > > Keigu > > > > > > > > > > Deepak > > > > > +91-9765089593 > > > > > [email protected] > > > > > > > > > > Skype: thumsupdeicool > > > > > Google talk: deicool > > > > > Blog: http://loveandfearless.wordpress.com > > > > > > > > > > Check out my Work at: > > > > > LinkedIn: http://in.linkedin.com/in/thumsupdeicool > > > > > > > > > > "Contribute to the world, environment and more : > > > > > http://www.gridrepublic.org > > > > > " > > > > > > > > > > > > > > > > > > > > > -- > > > Guten Tag > > > > > > > > > -- > > > Keigu > > > > > > Deepak > > > +91-9765089593 > > > [email protected] > > > > > > Skype: thumsupdeicool > > > Google talk: deicool > > > Blog: http://loveandfearless.wordpress.com > > > > > > Check out my Work at: > > > LinkedIn: http://in.linkedin.com/in/thumsupdeicool > > > > > > "Contribute to the world, environment and more : > > > http://www.gridrepublic.org > > > " > > > > > > > > > -- > Guten Tag > > > -- > Keigu > > Deepak > +91-9765089593 > [email protected] > > Skype: thumsupdeicool > Google talk: deicool > Blog: http://loveandfearless.wordpress.com > > Check out my Work at: > LinkedIn: http://in.linkedin.com/in/thumsupdeicool > > "Contribute to the world, environment and more : > http://www.gridrepublic.org > " >
