jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepak Shetty <shet...@gmail.com>
Subject Re: Resolve a JMeter variable using an external program
Date Tue, 18 Sep 2012 16:32:12 GMT
Hi
> I'm starting to think that the best (easiest) approach here is to simply
gracefully disallow jmx files
I agree. I dont see a way out of having to change your scripts or
specifying a set of guidelines everyone must follow.
For e.g. it is a rule that we never use full paths for our CSV files (they
are always relative)

regards
deepak

On Mon, Sep 17, 2012 at 9:08 AM, Oliver Lloyd <oliver_lloyd@hotmail.com>wrote:

> The trouble is I have no control over the structure of the jmx files -
> they can come from other teams / people - so the script has to adapt to
> what it gets given.
>
> I'm starting to think that the best (easiest) approach here is to simply
> gracefully disallow jmx files that do not use numeric literals where I need
> them to. Trying to support a solution that allows variables in these fields
> is probably just going to end up giving me grey hair and might never work
> that well.
>
>
> On 17 Sep 2012, at 16:51, sebb wrote:
>
> > On 17 September 2012 09:54, Oliver Lloyd <oliver_lloyd@hotmail.com>
> wrote:
> >> 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.
> >>
> >
> > Another way is to change the test plan so that it uses properties for
> > such things as loop count and ramp-up (with suitable defaults so the
> > test can be run without needing any to be defined).
> >
> > Then the controlling script can do the calculations and pass in the
> > appropriate properties - or you can create a user.properties file and
> > supply that.
> >
> > This is likely to be more flexible long term if you parameterise the
> > test appropriately.
> >
> >>
> >> 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" <ansoni@gmail.com>:
> >>>
> >>>> 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 <
> oliver_lloyd@hotmail.com>
> >>>> 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 <
> oliver_lloyd@hotmail.com
> >>>>> 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: user-unsubscribe@jmeter.apache.org
> >>>>>>> For additional commands, e-mail: user-help@jmeter.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> >>>>> For additional commands, e-mail: user-help@jmeter.apache.org
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> >>>> For additional commands, e-mail: user-help@jmeter.apache.org
> >>>>
> >>>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> >> For additional commands, e-mail: user-help@jmeter.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> > For additional commands, e-mail: user-help@jmeter.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message