On 02/03/2010, 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. > > > > > A single test is only 2 or 3 seconds, and I would like to configure > specifics. I see there is a method to determine the current number of > threads from StandardJMeterEngine, so going to try and see if i can safely > start up threads using this strategy... > > We need to determine thresholds of the application we are testing, so slowly > and consistently increase threads until stress limits are reached is an > important metric for us to be able to determine.
In that case, have a look at: http://jakarta.apache.org/jmeter/usermanual/best-practices.html#beanshell_server which can be used to adjust the throughput at run-time. > > > > > 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 > > " > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
