On Nov 30, 2010, at 9:52 AM, Deepak Shetty wrote:
> Hi
> to answer the first part - it might be better to do this more declaratively.
> You would need to combine the Constant Throughput Timer and the Constant
> Throughput Controller
> http://jakarta.apache.org/jmeter/usermanual/component_reference.html#Throughput_Controller
> Then you want 11 requests per second or 660 requests per minute. So add a
> constant throughput timer
>
> Thread Group
> +Loop Controller(say 1000 times)
> ++Constant Throughput Controller 1 (9% calculaled as 1*100/(1+1+1+1+7))
> +++New User Reg
> ++Constant Throughput Controller 2 (9%)
> +++Email Inuse
> ++Constant Throughput Controller 3 (9%)
> +++Update account
> ++Constant Throughput Controller 4 (9%)
> +++Update subscription
> ++Constant Throughput Controller 5 (64%)
> +++Login
> ++ Constant Throughput timer (all threads, 660)
>
Ah, that makes a lot of sense. I am in the process of switching this now to
see what effect it has.
Thanks very much for this answer.
> can you open a new thread for the other part of your question?
>
Done. I figured that is what I should do, but I was burning the midnight oil
and had to get home. Won't happen again.
> regards
> deepak
>
> On Mon, Nov 29, 2010 at 11:40 PM, Sean Berry <sbe...@2advanced.com> wrote:
>
>> Hello all,
>>
>> This is my first email to the list... I hope someone can help.
>>
>> I have developed an registration/authentication system that I now need to
>> load test. For my load test I have set goal for number requests / second.
>> These requests are to be distributed in a set ratio according to the
>> following:
>>
>> 1 New User Registration
>> 1 Check if email is in use
>> 1 Update Account
>> 1 Update Subscription (subset of update account)
>> 7 logins
>>
>> Currently I am using a BSF Preprocessor to set variables (user later in IF
>> controllers) to determine if these should run... so, for example:
>>
>> vars.put('register_ratio', ${__P(register_ratio)});
>> vars.put('emailInUse_ratio', ${__P(emailInUse_ratio)});
>> vars.put('login_ratio', ${__P(login_ratio)});
>> ...
>> etc
>>
>> --------
>>
>> var register_mod = parseInt(vars.get('counter'), 10) %
>> parseInt(vars.get('register_ratio'), 10);
>> if (register_mod == 0) {
>> vars.put('REGISTER', "yes");
>> } else {
>> vars.put('REGISTER', "no");
>> }
>> ...
>> etc
>>
>> --------
>>
>> Then, later I have IF Controllers for each:
>>
>> "${REGISTER}" == "yes"
>> "${LOGIN}" == "yes"
>> ...
>> etc
>>
>> --------
>>
>> This works as expected and I get the ratios of each request I am trying to
>> achieve. So, the first question:
>> Is this the "right" way to do this? Is there a better way?
>>
>> My second question, which may warrant a different thread has to do with
>> collecting the output data. Currently, I am running a server on 7 machines.
>> I have a python script that port scans all local IPs for 1099. The python
>> process then gathers the output to create a report. The output works fine
>> if I include a "Debug Sampler" even though I have everything set to False.
>> I am only able to get output (via CLI or GUI) if I have the Debug Sampler
>> enabled. I think this is because all of my samplers (WebService SOAP) are
>> inside of the IF Logic Controllers. If I put a Summary Report or View
>> Results Tree inside the IF Controllers then I get output, but if they are
>> not inside then I get nothing with the Debug Sampler turned off. I know I
>> must be doing something wrong and was looking for some help on this as well.
>> Here is a screenshot of my current setup.
>> http://i52.tinypic.com/i1cm4n.jpg
>>
>> If you need any more information please feel free to ask.
>>
>> As a side note, I have taken a lot of the logic from the perl script that
>> generates graphs from the output saved from the Aggregate Graph and have
>> ported it over to Python, adding a bunch of additional reporting information
>> and wrapping it up in a nice little web interface. Once completed, I would
>> like to contribute the source back to the community. Here is a partial
>> screenshot:
>> http://i53.tinypic.com/2zxxhj8.png
>>
>> Anyway, thanks for any help!
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org
For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
