Hey, that's actually a very good idea. It might get tricky if the thread count
were smaller than the size of the farm but it's a much better solution than my
first thought. Thanks.
On 17 Sep 2012, at 09:00, Shmuel Krakower wrote:
> Hi
> One idea is instead of parsing the value; wrap it.
> For example said that the thread group users is 50 and you have 5 machines
> in the farm you would need to divide by 5 with eval expression like
> ${__eval(50 / 5)} this can be the value in the thread group configuration.
>
> Now you dont care if its a fixed value or a variable.
> בתאריך 2012 9 17 07:35, מאת "Anthony Johnson" <[email protected]>:
>
>> I assume that you are trying to spread the load as equally as possible?
>>
>> Could you would some magic with the Beanshell Server?
>>
>> Perhaps you can block every test in a setup Thread group or a
>> Once-Only Controller until your test distribution is done and then
>> open the gates?
>>
>> Good luck,
>>
>> Anthony
>>
>> On Sun, Sep 16, 2012 at 9:48 PM, Oliver Lloyd <[email protected]>
>> wrote:
>>> No really, sadly this is the problem statement.
>>>
>>> So, what I'm working on is a program that takes the jmeter jmx file and
>> farms it out over a bunch of machines. Before it does this it parses the
>> jmx to get things like thread counts and references to csv files - you need
>> these to make the process useful.
>>>
>>> It's all very easy if I could be sure that the values will always be
>> absolute but the use case is such that this is simply not the case - so I'm
>> looking for the best approach to handle it. As far as I can see, the best
>> way to find out what ${myVar} equals is to fire up JMeter and see what it
>> get's set to but then I really don't want to do that, it's messy and
>> potentially not even possible. Is there an alternative?
>>>
>>>
>>> On 16 Sep 2012, at 22:33, Deepak Shetty wrote:
>>>
>>>>> I want to take this jmx xml file and parse it to read the location of
>> the
>>>> file so I can do stuff with it (before I actually run the >test)
>>>> I cant help but feel that this is a proposed solution to a problem
>> rather
>>>> than the problem itself.
>>>> Literally you are asking the equivalent of I have a java class , can i
>>>> figure out the value of a variable without running the java class. In
>> which
>>>> case the answer is no. However a variable is just initial state +
>> algorithm
>>>> so you can always figure out its value it would have if you are willing
>> to
>>>> duplicate the steps.(or in your case , how does JMeter determine
>>>> ${myTestRoot}) or you can specify your original problem statement and
>> see
>>>> if anyone has a different suggestion.
>>>>
>>>> regards
>>>> deepak
>>>>
>>>>
>>>>
>>>> On Sun, Sep 16, 2012 at 5:27 AM, Oliver Lloyd <[email protected]
>>> wrote:
>>>>
>>>>> Is it possible to resolve the value of a jmeter variable from an
>> external
>>>>> program?
>>>>>
>>>>> So, if I have a jmx that has, for example, a CSV Config control that
>> has a
>>>>> literal path of:
>>>>>
>>>>> ${myTestRoot}/some/other/dir/myfile.csv
>>>>>
>>>>> Using an external program, I want to take this jmx xml file and parse
>> it
>>>>> to read the location of the file so I can do stuff with it (before I
>>>>> actually run the test). But because there is a variable in the literal
>>>>> value of the file path I obviously cannot.
>>>>>
>>>>> What I would like to do is work out a way (probably via some form of
>>>>> temporary plugin) to start the jmeter process in such a way that the
>>>>> variable is instantiated and I am able to get its value, but without
>>>>> actually starting the test.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>>
>>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
