in the latest release, there's new controller called "include controller"

what you can do is create your requests and put them under a simple
controller. Save the controller as a module.

then in the actual test plan, use the include controller.

test plan -
    - threadgroup A (delay 1000)
        - include controller
    - threadgroup B (delay 5000)
        - include controller
    - threadgroup C (delay 10000)
        - include controller

would that work for you?

peter


On 11/29/05, Noam Paz <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
>
> Yes, this would surely work.
> However replicating the testsuite (some of my testsuites include more than
> 100 different requests) many times results in awkward, hard to maintain jmx
> files, hence the need for more elegant solution.
> A desireable solution for me would include the following enhancement
> (properties) on the Thread Group panel:
> - number of threads to start with
> - thread increasement (after elapsed time T or after N loops has finished)
> - maximal thread count
> If I recall correctly there exist interest in the group for such an
> enhancement.
>
> Best regards / Viele Grüße
>
> Noam Paz
>
>
>
>
>
>              Peter Lin <[EMAIL PROTECTED]>
>
>              29.11.200517:47                                                  
>                                                                               
>                                                                               
>                                                                               
>                                                                               
>                                                                               
>                                                                               
>                                                                               
>                                                                               
>                                                                               
>                                                                               
>                                                                               
>                                                   To
>
> JMeter Users List <jmeter-user@jakarta.apache.org>
>
> cc
>
> Please respond to
>
> "JMeter Users List" <jmeter-user@jakarta.apache.org>
> Subject
>
> Re: How to periodically Increase the number of threads during load test
>
>
>
>
>
>
>
>
>
>
> a simple option is this
>
> test plan -
>    - thread group (delay 1000)
>    - thread group (delay 5000)
>    - thread group (delay 10000)
>
>
> peter
>
>
> On 11/29/05, Noam Paz <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >
> >
> >
> > Hi Sebb,
> > you wrote
> > >>>
> > What we tend to do is to use a fixed number of threads, but vary the
> > throughput using a variable or property. The variable can be changed
> > by reading a file, or a property can be changed remotely using the
> > beanshell server - see jmeter.properties for info on starting it.
> > <<<
> > since this question arises every now and then - is it possible to
> > elaborate on it ? Do you have a small example handy?
> >
> > Best regards / Viele Grüße
> >
> > Noam Paz
> >
> >
> >
> >
> >
> >              sebb <[EMAIL PROTECTED]>
> >
> >              29.11.200515
> :48                                                                           
>                                                                               
>                                                                               
>                                                                               
>                                                                               
>                                                                               
>                                                                               
>                                                                               
>                                                                               
>                                                                               
>                                                                               
>                                                                               
>                          To
> >
> > JMeter Users List <jmeter-user@jakarta.apache.org>
> >
> > cc
> >
> > Please respond to
> >
> > "JMeter Users List" <jmeter-user@jakarta.apache.org>
> > Subject
> >
> > Re: How to periodically Increase the number of threads during load test
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On 29/11/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > Hello,
> > >
> > > In order to load testing the web application, I would like Jmeter
> > > to Increase the number of threads of a thread group, each 30 minutes.
> > >
> > > How could I do that?
> > >
> >
> > Create a Bugzilla enhancement request and wait ;-)
> > It's not directly possible at present.
> >
> > However, you can gradually increase the number of active threads by
> > choosing a suitable ramp-up time - e.g. 100 threads, ramp-up 1000
> > would create 100 threads, but start them every 10 seconds.
> >
> > Or you could have multiple thread groups, and use the startup delay to
> > start them in sequence.
> >
> > What we tend to do is to use a fixed number of threads, but vary the
> > throughput using a variable or property. The variable can be changed
> > by reading a file, or a property can be changed remotely using the
> > beanshell server - see jmeter.properties for info on starting it.
> >
> > S.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
> > --
> >
> > Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte
> > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
> E-Mail
> > irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender
> und
> > vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
> > Weitergabe dieser Mail ist nicht gestattet.
> >
> > This e-mail may contain confidential and/or privileged information. If
> you
> > are not the intended recipient (or have received this e-mail in error)
> > please notify the sender immediately and destroy this e-mail. Any
> > unauthorized copying, disclosure or distribution of the material in this
> > e-mail is strictly forbidden.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
>
> --
>
> Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
> irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und
> vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
> Weitergabe dieser Mail ist nicht gestattet.
>
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorized copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to