In my view, most of the time scripting is not really needed (I have not used it
for our load-tests ever)
most of the time you can get the same result by preparing a csv file (using
perl, python, etc) and read that
into the variable(s) that would be set by your script. If needed you can put
the randomizing step in the script
that starts the loadtest before jmeter is called.
The example Phillipe gives can be done with standard jmeter without scripting
and without using a csv file
by placing the array of values into a jmeter variable and picking a random
value from that in a regexp extractor
for instance.
For what it's worth I side with Sebb on this one, it is easy enough to get the
Groovy jar when you install
jmeter. It is a one-time activity, and before you know it, people will propose
adding JRuby, Jython etc :-)
regards, Andre
-----Original Message-----
From: Danny Lade [mailto:[email protected]]
Sent: 17 July 2013 08:50
To: [email protected]
Subject: AW: Groovy
Sorry for my intervention again, but as Philippe wrote, in our experience also
there is no way to handle a complex load test without scripting. Yes, we need
less scripting, but we need it.
And, as I already mentioned, in an external high load environment (take
"http://blazemeter.com/"; for example) You cannot ship Java-Tests or own
Java-Plugins to the load servers, but scripts.
However, we don't care about integrating groovy, we just need fast running
scripts, one or the other way.
VG Danny
> -----Ursprüngliche Nachricht-----
> Von: Philippe Mouawad [mailto:[email protected]]
> Gesendet: Dienstag, 16. Juli 2013 23:14
> An: [email protected]
> Betreff: Re: Groovy
>
> But sebb,
> For me, Scripting is not for prototyping in my experience.
> In the last 10 Load Testing missions I made recently I always had to
> script at some point.
> I remember packaging a JAR years ago, it is more intended to
> developpers and takes more configuration than scripting.
> It is really much easier to script than package a Jar with classes no ?
>
> Also with syntax coloring we bring a great enhancement on it, so why
> not make it efficient by default ?
>
> Also Groovy+Caching has nearly same performances as classes inside a Jar.
>
> We should make performances great by default and not rely on users
> tune or use the best option, don't you think so ?
>
