On 19 July 2013 07:57, Philippe Mouawad <[email protected]> wrote: > I disagree about scripting, but I agree on possible requests for additions > of other jars. > > So Ok for not packaging groovy in it. > But I suggest we add something like this to changes and best - practices: > > - For intensive load testing, the recommended scripting language is one > that implements Compilable. Groovy is one of them, Beanshell, not > Jacascript do as of release date.
OK, good idea. > Regards > Philippe > > > On Wednesday, July 17, 2013, van Dalen, Andre wrote: > >> 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] <javascript:;>] >> Sent: 17 July 2013 08:50 >> To: [email protected] <javascript:;> >> 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] <javascript:;>] >> > Gesendet: Dienstag, 16. Juli 2013 23:14 >> > An: [email protected] <javascript:;> >> > 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 ? >> > >> > > > -- > Cordialement. > Philippe Mouawad.
