You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Philippe Mouawad <ph...@gmail.com> on 2013/07/02 23:43:04 UTC
Re: Groovy
hello,
so we include it ?
It's +1 for me:
- faster than beanshell
- maintaned and jdk6 syntax can be used
- big community
- embedding it will encourage its usage
Regards
Philippe
On Sunday, June 30, 2013, Philippe Mouawad wrote:
> Hello Sebb,
> It's Apache 2 license
> groovy-all.jar is around 6m
>
> Regards
> Philippe
> On Sun, Jun 30, 2013 at 3:41 PM, sebb <sebbaz@gmail.com<javascript:_e({}, 'cvml', 'sebbaz@gmail.com');>
> > wrote:
>
>> On 29 June 2013 22:57, Philippe Mouawad <philippe.mouawad@gmail.com<javascript:_e({}, 'cvml', 'philippe.mouawad@gmail.com');>>
>> wrote:
>> > Hello,
>> > what about embedding groovy in next release so that it is automatically
>> > available to JSR223 sampler ?
>>
>> How big is it?
>> What is the license?
>>
>> >
>> >
>> > Regards
>> > Philippe
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>
--
Cordialement.
Philippe Mouawad.
Re: Groovy
Posted by Philippe Mouawad <ph...@gmail.com>.
I will commit the template for MongoDB in Groovy and cross fingers you will
agree to embed Groovy-all.jar ;-)
I will need in this case to document that you must download groovy, extract
groovy-all.jar in lib and restart.
Regards
Philippe
On Tue, Jul 16, 2013 at 11:14 PM, Philippe Mouawad <
philippe.mouawad@gmail.com> wrote:
> 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 ?
>
> Thanks
> Regards
> Philippe
>
>
> On Tue, Jul 16, 2013 at 11:05 PM, sebb <se...@gmail.com> wrote:
>
>> I'll say again: scripting is intended for prototyping. It is not
>> intended for the casual user.
>>
>> The BeanShell jars are really only included because Beanshell was the
>> first scripting language included; at the time JSR-223 did not exist
>> and BSF was not entirely functional. Had JSR223/BSF existed, we
>> probably would not be shipping BSH with JMeter. But it cannot now be
>> dropped easily.
>>
>> On 16 July 2013 21:45, Philippe Mouawad <ph...@gmail.com>
>> wrote:
>> > Hello,
>> > I bounce again on this one as I had an interesting experience this
>> evening;
>> >
>> > I was creating a Template for MongoDB, I started creating it with
>> > Beanshell, and found it strange that throughput was so bad
>> > 25 Threads, no pause time, one insert, one count:
>> >
>> > - Generate Summary Results = 95514 in 300s = 318.3/s Avg: 74
>> > Min: 2 Max: 536 Err: 0 (0.00%)
>> >
>> >
>> > I analyzed a bit and to my surprise time was spent in Beanshell
>> > So I decided to write the same in JSR223+Groovy+Caching:
>> >
>> >
>> > - Generate Summary Results = 1171779 in 300s = 3905.8/s Avg: 6
>> > Min: 0 Max: 648 Err: 0 (0.00%)
>> >
>> >
>> > Results:
>> >
>> > - Groovy cached performs > 11 times better than Beanshell.
>> >
>> >
>> > *So I am convinced we should ship Groovy with JMeter to encourage users
>> to
>> > use it by default.*
>> >
>> > Look at the comment at bottom of this page (I am not saying it is
>> > representative but It is interesting to know how users think and use
>> JMeter
>> > sometimes)
>> >
>> > -
>> >
>> http://www.ubik-ingenierie.com/blog/jmeter_control_percentage_of_sampler/
>> >
>> > What does he say ?
>> >
>> > => The main advantage is that BeanShell is installed by *default* with
>> > JMeter
>> >
>> > Opinions ?
>> >
>> >
>> >
>> >
>> > On Fri, Jul 5, 2013 at 5:30 PM, sebb <se...@gmail.com> wrote:
>> >
>> >> On 5 July 2013 16:24, Danny Lade <D....@bigpoint.net> wrote:
>> >> >> -----Ursprüngliche Nachricht-----
>> >> >> Von: sebb [mailto:sebbaz@gmail.com]
>> >> >> Gesendet: Freitag, 5. Juli 2013 16:29
>> >> >> An: dev@jmeter.apache.org
>> >> >> Betreff: Re: Groovy
>> >> >>
>> >> >> > I'm not sure how could you know the code about JSR223TestElement
>> is
>> >> >> > implementing the support for "script compilation caching", so here
>> >> comes
>> >> >> some short code:
>> >> >> >
>> >> >> > processFileOrScript()
>> >> >> > // Hack as in bsh-2.0b5.jar BshScriptEngine implements
>> >> Compilable but
>> >> >> throws new Error
>> >> >> > boolean supportsCompilable = scriptEngine instanceof
>> >> Compilable
>> >> >> > &&
>> >> >> >
>> !(scriptEngine.getClass().getName().equals("bsh.engine.BshScriptEngine
>> >> >> > "));
>> >> >> >
>> >> >> > Because the JavaScriptEngine is based on the BshScriptEngine the
>> >> "script
>> >> >> compilation caching"
>> >> >> > isn't available for Java, but it is available for groovy.
>> >> >>
>> >> >> Which JavaScriptEngine?
>> >> >>
>> >> > There is no physical implementation, but if you use the "JSR223
>> Sampler"
>> >> it provides the language "Java". This is made via the
>> >> BshScriptEngineFactory which provides the information it also "speaks"
>> Java.
>> >>
>> >> OK, I see.
>> >>
>> >> > (see
>> >>
>> https://code.google.com/p/beanshell2/source/browse/trunk/src/bsh/BshScriptEngineFactory.java?r=94
>> >> )
>> >> > However, the "script compilation caching" does not work for Java
>> >> (provided by BshScriptEngine).
>> >> >
>> >> > Besides that, it seems they removed the Java support in newer
>> versions
>> >> (see same link, but newest version). You should consider that if you
>> think
>> >> about using "bsh-2.1b5.jar" in the future.
>> >>
>> >> No, we cannot use beanshell2 from that source as it is GPL.
>> >> However the original beanshell code is hopefully coming to Apache.
>> >>
>> >> >> > I'm not saying "you must install groovy" , I just want to be sure
>> >> >> > having a scripting engine with "script compilation caching"
>> working
>> >> (or without
>> >> >> any synchronization during runtime).
>> >> >>
>> >> >> What I am saying is that there is no need to include Groovy in the
>> >> JMeter binary
>> >> >> release.
>> >> >> It works just as well if it is downloaded separately.
>> >> >>
>> >> >> And if the BSH Compilable bug can be fixed, users could then use
>> >> BeanShell.
>> >> >>
>> >> > It's the same on me, I just want to point out the "script compilation
>> >> caching" with BeanShell.
>> >> > All I did was to suggest possible solutions (IMO), the decision is
>> all
>> >> yours.
>> >> >
>> >> > Greetings Danny
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>
--
Cordialement.
Philippe Mouawad.
Re: Groovy
Posted by sebb <se...@gmail.com>.
On 19 July 2013 07:57, Philippe Mouawad <ph...@gmail.com> 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:D.Lade@bigpoint.net <javascript:;>]
>> Sent: 17 July 2013 08:50
>> To: dev@jmeter.apache.org <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:philippe.mouawad@gmail.com <javascript:;>]
>> > Gesendet: Dienstag, 16. Juli 2013 23:14
>> > An: dev@jmeter.apache.org <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.
Re: Groovy
Posted by Philippe Mouawad <ph...@gmail.com>.
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.
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:D.Lade@bigpoint.net <javascript:;>]
> Sent: 17 July 2013 08:50
> To: dev@jmeter.apache.org <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:philippe.mouawad@gmail.com <javascript:;>]
> > Gesendet: Dienstag, 16. Juli 2013 23:14
> > An: dev@jmeter.apache.org <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.
RE: Groovy
Posted by "van Dalen, Andre" <an...@atos.net>.
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:D.Lade@bigpoint.net]
Sent: 17 July 2013 08:50
To: dev@jmeter.apache.org
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:philippe.mouawad@gmail.com]
> Gesendet: Dienstag, 16. Juli 2013 23:14
> An: dev@jmeter.apache.org
> 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 ?
>
AW: Groovy
Posted by Danny Lade <D....@bigpoint.net>.
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:philippe.mouawad@gmail.com]
> Gesendet: Dienstag, 16. Juli 2013 23:14
> An: dev@jmeter.apache.org
> 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 ?
>
Re: Groovy
Posted by Philippe Mouawad <ph...@gmail.com>.
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 ?
Thanks
Regards
Philippe
On Tue, Jul 16, 2013 at 11:05 PM, sebb <se...@gmail.com> wrote:
> I'll say again: scripting is intended for prototyping. It is not
> intended for the casual user.
>
> The BeanShell jars are really only included because Beanshell was the
> first scripting language included; at the time JSR-223 did not exist
> and BSF was not entirely functional. Had JSR223/BSF existed, we
> probably would not be shipping BSH with JMeter. But it cannot now be
> dropped easily.
>
> On 16 July 2013 21:45, Philippe Mouawad <ph...@gmail.com>
> wrote:
> > Hello,
> > I bounce again on this one as I had an interesting experience this
> evening;
> >
> > I was creating a Template for MongoDB, I started creating it with
> > Beanshell, and found it strange that throughput was so bad
> > 25 Threads, no pause time, one insert, one count:
> >
> > - Generate Summary Results = 95514 in 300s = 318.3/s Avg: 74
> > Min: 2 Max: 536 Err: 0 (0.00%)
> >
> >
> > I analyzed a bit and to my surprise time was spent in Beanshell
> > So I decided to write the same in JSR223+Groovy+Caching:
> >
> >
> > - Generate Summary Results = 1171779 in 300s = 3905.8/s Avg: 6
> > Min: 0 Max: 648 Err: 0 (0.00%)
> >
> >
> > Results:
> >
> > - Groovy cached performs > 11 times better than Beanshell.
> >
> >
> > *So I am convinced we should ship Groovy with JMeter to encourage users
> to
> > use it by default.*
> >
> > Look at the comment at bottom of this page (I am not saying it is
> > representative but It is interesting to know how users think and use
> JMeter
> > sometimes)
> >
> > -
> >
> http://www.ubik-ingenierie.com/blog/jmeter_control_percentage_of_sampler/
> >
> > What does he say ?
> >
> > => The main advantage is that BeanShell is installed by *default* with
> > JMeter
> >
> > Opinions ?
> >
> >
> >
> >
> > On Fri, Jul 5, 2013 at 5:30 PM, sebb <se...@gmail.com> wrote:
> >
> >> On 5 July 2013 16:24, Danny Lade <D....@bigpoint.net> wrote:
> >> >> -----Ursprüngliche Nachricht-----
> >> >> Von: sebb [mailto:sebbaz@gmail.com]
> >> >> Gesendet: Freitag, 5. Juli 2013 16:29
> >> >> An: dev@jmeter.apache.org
> >> >> Betreff: Re: Groovy
> >> >>
> >> >> > I'm not sure how could you know the code about JSR223TestElement is
> >> >> > implementing the support for "script compilation caching", so here
> >> comes
> >> >> some short code:
> >> >> >
> >> >> > processFileOrScript()
> >> >> > // Hack as in bsh-2.0b5.jar BshScriptEngine implements
> >> Compilable but
> >> >> throws new Error
> >> >> > boolean supportsCompilable = scriptEngine instanceof
> >> Compilable
> >> >> > &&
> >> >> >
> !(scriptEngine.getClass().getName().equals("bsh.engine.BshScriptEngine
> >> >> > "));
> >> >> >
> >> >> > Because the JavaScriptEngine is based on the BshScriptEngine the
> >> "script
> >> >> compilation caching"
> >> >> > isn't available for Java, but it is available for groovy.
> >> >>
> >> >> Which JavaScriptEngine?
> >> >>
> >> > There is no physical implementation, but if you use the "JSR223
> Sampler"
> >> it provides the language "Java". This is made via the
> >> BshScriptEngineFactory which provides the information it also "speaks"
> Java.
> >>
> >> OK, I see.
> >>
> >> > (see
> >>
> https://code.google.com/p/beanshell2/source/browse/trunk/src/bsh/BshScriptEngineFactory.java?r=94
> >> )
> >> > However, the "script compilation caching" does not work for Java
> >> (provided by BshScriptEngine).
> >> >
> >> > Besides that, it seems they removed the Java support in newer versions
> >> (see same link, but newest version). You should consider that if you
> think
> >> about using "bsh-2.1b5.jar" in the future.
> >>
> >> No, we cannot use beanshell2 from that source as it is GPL.
> >> However the original beanshell code is hopefully coming to Apache.
> >>
> >> >> > I'm not saying "you must install groovy" , I just want to be sure
> >> >> > having a scripting engine with "script compilation caching" working
> >> (or without
> >> >> any synchronization during runtime).
> >> >>
> >> >> What I am saying is that there is no need to include Groovy in the
> >> JMeter binary
> >> >> release.
> >> >> It works just as well if it is downloaded separately.
> >> >>
> >> >> And if the BSH Compilable bug can be fixed, users could then use
> >> BeanShell.
> >> >>
> >> > It's the same on me, I just want to point out the "script compilation
> >> caching" with BeanShell.
> >> > All I did was to suggest possible solutions (IMO), the decision is all
> >> yours.
> >> >
> >> > Greetings Danny
> >> >
> >>
> >
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>
--
Cordialement.
Philippe Mouawad.
Re: Groovy
Posted by sebb <se...@gmail.com>.
I'll say again: scripting is intended for prototyping. It is not
intended for the casual user.
The BeanShell jars are really only included because Beanshell was the
first scripting language included; at the time JSR-223 did not exist
and BSF was not entirely functional. Had JSR223/BSF existed, we
probably would not be shipping BSH with JMeter. But it cannot now be
dropped easily.
On 16 July 2013 21:45, Philippe Mouawad <ph...@gmail.com> wrote:
> Hello,
> I bounce again on this one as I had an interesting experience this evening;
>
> I was creating a Template for MongoDB, I started creating it with
> Beanshell, and found it strange that throughput was so bad
> 25 Threads, no pause time, one insert, one count:
>
> - Generate Summary Results = 95514 in 300s = 318.3/s Avg: 74
> Min: 2 Max: 536 Err: 0 (0.00%)
>
>
> I analyzed a bit and to my surprise time was spent in Beanshell
> So I decided to write the same in JSR223+Groovy+Caching:
>
>
> - Generate Summary Results = 1171779 in 300s = 3905.8/s Avg: 6
> Min: 0 Max: 648 Err: 0 (0.00%)
>
>
> Results:
>
> - Groovy cached performs > 11 times better than Beanshell.
>
>
> *So I am convinced we should ship Groovy with JMeter to encourage users to
> use it by default.*
>
> Look at the comment at bottom of this page (I am not saying it is
> representative but It is interesting to know how users think and use JMeter
> sometimes)
>
> -
> http://www.ubik-ingenierie.com/blog/jmeter_control_percentage_of_sampler/
>
> What does he say ?
>
> => The main advantage is that BeanShell is installed by *default* with
> JMeter
>
> Opinions ?
>
>
>
>
> On Fri, Jul 5, 2013 at 5:30 PM, sebb <se...@gmail.com> wrote:
>
>> On 5 July 2013 16:24, Danny Lade <D....@bigpoint.net> wrote:
>> >> -----Ursprüngliche Nachricht-----
>> >> Von: sebb [mailto:sebbaz@gmail.com]
>> >> Gesendet: Freitag, 5. Juli 2013 16:29
>> >> An: dev@jmeter.apache.org
>> >> Betreff: Re: Groovy
>> >>
>> >> > I'm not sure how could you know the code about JSR223TestElement is
>> >> > implementing the support for "script compilation caching", so here
>> comes
>> >> some short code:
>> >> >
>> >> > processFileOrScript()
>> >> > // Hack as in bsh-2.0b5.jar BshScriptEngine implements
>> Compilable but
>> >> throws new Error
>> >> > boolean supportsCompilable = scriptEngine instanceof
>> Compilable
>> >> > &&
>> >> > !(scriptEngine.getClass().getName().equals("bsh.engine.BshScriptEngine
>> >> > "));
>> >> >
>> >> > Because the JavaScriptEngine is based on the BshScriptEngine the
>> "script
>> >> compilation caching"
>> >> > isn't available for Java, but it is available for groovy.
>> >>
>> >> Which JavaScriptEngine?
>> >>
>> > There is no physical implementation, but if you use the "JSR223 Sampler"
>> it provides the language "Java". This is made via the
>> BshScriptEngineFactory which provides the information it also "speaks" Java.
>>
>> OK, I see.
>>
>> > (see
>> https://code.google.com/p/beanshell2/source/browse/trunk/src/bsh/BshScriptEngineFactory.java?r=94
>> )
>> > However, the "script compilation caching" does not work for Java
>> (provided by BshScriptEngine).
>> >
>> > Besides that, it seems they removed the Java support in newer versions
>> (see same link, but newest version). You should consider that if you think
>> about using "bsh-2.1b5.jar" in the future.
>>
>> No, we cannot use beanshell2 from that source as it is GPL.
>> However the original beanshell code is hopefully coming to Apache.
>>
>> >> > I'm not saying "you must install groovy" , I just want to be sure
>> >> > having a scripting engine with "script compilation caching" working
>> (or without
>> >> any synchronization during runtime).
>> >>
>> >> What I am saying is that there is no need to include Groovy in the
>> JMeter binary
>> >> release.
>> >> It works just as well if it is downloaded separately.
>> >>
>> >> And if the BSH Compilable bug can be fixed, users could then use
>> BeanShell.
>> >>
>> > It's the same on me, I just want to point out the "script compilation
>> caching" with BeanShell.
>> > All I did was to suggest possible solutions (IMO), the decision is all
>> yours.
>> >
>> > Greetings Danny
>> >
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: Groovy
Posted by Philippe Mouawad <ph...@gmail.com>.
Hello,
I bounce again on this one as I had an interesting experience this evening;
I was creating a Template for MongoDB, I started creating it with
Beanshell, and found it strange that throughput was so bad
25 Threads, no pause time, one insert, one count:
- Generate Summary Results = 95514 in 300s = 318.3/s Avg: 74
Min: 2 Max: 536 Err: 0 (0.00%)
I analyzed a bit and to my surprise time was spent in Beanshell
So I decided to write the same in JSR223+Groovy+Caching:
- Generate Summary Results = 1171779 in 300s = 3905.8/s Avg: 6
Min: 0 Max: 648 Err: 0 (0.00%)
Results:
- Groovy cached performs > 11 times better than Beanshell.
*So I am convinced we should ship Groovy with JMeter to encourage users to
use it by default.*
Look at the comment at bottom of this page (I am not saying it is
representative but It is interesting to know how users think and use JMeter
sometimes)
-
http://www.ubik-ingenierie.com/blog/jmeter_control_percentage_of_sampler/
What does he say ?
=> The main advantage is that BeanShell is installed by *default* with
JMeter
Opinions ?
On Fri, Jul 5, 2013 at 5:30 PM, sebb <se...@gmail.com> wrote:
> On 5 July 2013 16:24, Danny Lade <D....@bigpoint.net> wrote:
> >> -----Ursprüngliche Nachricht-----
> >> Von: sebb [mailto:sebbaz@gmail.com]
> >> Gesendet: Freitag, 5. Juli 2013 16:29
> >> An: dev@jmeter.apache.org
> >> Betreff: Re: Groovy
> >>
> >> > I'm not sure how could you know the code about JSR223TestElement is
> >> > implementing the support for "script compilation caching", so here
> comes
> >> some short code:
> >> >
> >> > processFileOrScript()
> >> > // Hack as in bsh-2.0b5.jar BshScriptEngine implements
> Compilable but
> >> throws new Error
> >> > boolean supportsCompilable = scriptEngine instanceof
> Compilable
> >> > &&
> >> > !(scriptEngine.getClass().getName().equals("bsh.engine.BshScriptEngine
> >> > "));
> >> >
> >> > Because the JavaScriptEngine is based on the BshScriptEngine the
> "script
> >> compilation caching"
> >> > isn't available for Java, but it is available for groovy.
> >>
> >> Which JavaScriptEngine?
> >>
> > There is no physical implementation, but if you use the "JSR223 Sampler"
> it provides the language "Java". This is made via the
> BshScriptEngineFactory which provides the information it also "speaks" Java.
>
> OK, I see.
>
> > (see
> https://code.google.com/p/beanshell2/source/browse/trunk/src/bsh/BshScriptEngineFactory.java?r=94
> )
> > However, the "script compilation caching" does not work for Java
> (provided by BshScriptEngine).
> >
> > Besides that, it seems they removed the Java support in newer versions
> (see same link, but newest version). You should consider that if you think
> about using "bsh-2.1b5.jar" in the future.
>
> No, we cannot use beanshell2 from that source as it is GPL.
> However the original beanshell code is hopefully coming to Apache.
>
> >> > I'm not saying "you must install groovy" , I just want to be sure
> >> > having a scripting engine with "script compilation caching" working
> (or without
> >> any synchronization during runtime).
> >>
> >> What I am saying is that there is no need to include Groovy in the
> JMeter binary
> >> release.
> >> It works just as well if it is downloaded separately.
> >>
> >> And if the BSH Compilable bug can be fixed, users could then use
> BeanShell.
> >>
> > It's the same on me, I just want to point out the "script compilation
> caching" with BeanShell.
> > All I did was to suggest possible solutions (IMO), the decision is all
> yours.
> >
> > Greetings Danny
> >
>
--
Cordialement.
Philippe Mouawad.
Re: Groovy
Posted by sebb <se...@gmail.com>.
On 5 July 2013 16:24, Danny Lade <D....@bigpoint.net> wrote:
>> -----Ursprüngliche Nachricht-----
>> Von: sebb [mailto:sebbaz@gmail.com]
>> Gesendet: Freitag, 5. Juli 2013 16:29
>> An: dev@jmeter.apache.org
>> Betreff: Re: Groovy
>>
>> > I'm not sure how could you know the code about JSR223TestElement is
>> > implementing the support for "script compilation caching", so here comes
>> some short code:
>> >
>> > processFileOrScript()
>> > // Hack as in bsh-2.0b5.jar BshScriptEngine implements Compilable but
>> throws new Error
>> > boolean supportsCompilable = scriptEngine instanceof Compilable
>> > &&
>> > !(scriptEngine.getClass().getName().equals("bsh.engine.BshScriptEngine
>> > "));
>> >
>> > Because the JavaScriptEngine is based on the BshScriptEngine the "script
>> compilation caching"
>> > isn't available for Java, but it is available for groovy.
>>
>> Which JavaScriptEngine?
>>
> There is no physical implementation, but if you use the "JSR223 Sampler" it provides the language "Java". This is made via the BshScriptEngineFactory which provides the information it also "speaks" Java.
OK, I see.
> (see https://code.google.com/p/beanshell2/source/browse/trunk/src/bsh/BshScriptEngineFactory.java?r=94)
> However, the "script compilation caching" does not work for Java (provided by BshScriptEngine).
>
> Besides that, it seems they removed the Java support in newer versions (see same link, but newest version). You should consider that if you think about using "bsh-2.1b5.jar" in the future.
No, we cannot use beanshell2 from that source as it is GPL.
However the original beanshell code is hopefully coming to Apache.
>> > I'm not saying "you must install groovy" , I just want to be sure
>> > having a scripting engine with "script compilation caching" working (or without
>> any synchronization during runtime).
>>
>> What I am saying is that there is no need to include Groovy in the JMeter binary
>> release.
>> It works just as well if it is downloaded separately.
>>
>> And if the BSH Compilable bug can be fixed, users could then use BeanShell.
>>
> It's the same on me, I just want to point out the "script compilation caching" with BeanShell.
> All I did was to suggest possible solutions (IMO), the decision is all yours.
>
> Greetings Danny
>
AW: Groovy
Posted by Danny Lade <D....@bigpoint.net>.
> -----Ursprüngliche Nachricht-----
> Von: sebb [mailto:sebbaz@gmail.com]
> Gesendet: Freitag, 5. Juli 2013 16:29
> An: dev@jmeter.apache.org
> Betreff: Re: Groovy
>
> > I'm not sure how could you know the code about JSR223TestElement is
> > implementing the support for "script compilation caching", so here comes
> some short code:
> >
> > processFileOrScript()
> > // Hack as in bsh-2.0b5.jar BshScriptEngine implements Compilable but
> throws new Error
> > boolean supportsCompilable = scriptEngine instanceof Compilable
> > &&
> > !(scriptEngine.getClass().getName().equals("bsh.engine.BshScriptEngine
> > "));
> >
> > Because the JavaScriptEngine is based on the BshScriptEngine the "script
> compilation caching"
> > isn't available for Java, but it is available for groovy.
>
> Which JavaScriptEngine?
>
There is no physical implementation, but if you use the "JSR223 Sampler" it provides the language "Java". This is made via the BshScriptEngineFactory which provides the information it also "speaks" Java.
(see https://code.google.com/p/beanshell2/source/browse/trunk/src/bsh/BshScriptEngineFactory.java?r=94)
However, the "script compilation caching" does not work for Java (provided by BshScriptEngine).
Besides that, it seems they removed the Java support in newer versions (see same link, but newest version). You should consider that if you think about using "bsh-2.1b5.jar" in the future.
> > I'm not saying "you must install groovy" , I just want to be sure
> > having a scripting engine with "script compilation caching" working (or without
> any synchronization during runtime).
>
> What I am saying is that there is no need to include Groovy in the JMeter binary
> release.
> It works just as well if it is downloaded separately.
>
> And if the BSH Compilable bug can be fixed, users could then use BeanShell.
>
It's the same on me, I just want to point out the "script compilation caching" with BeanShell.
All I did was to suggest possible solutions (IMO), the decision is all yours.
Greetings Danny
Re: Groovy
Posted by sebb <se...@gmail.com>.
On 5 July 2013 15:09, Danny Lade <D....@bigpoint.net> wrote:
>> > For the "groovy thing":
>> > I would really wish to have scripts that are cached. But currently (using 2.9) this
>> functionality can't be used for Java or beanshell.
>> > As I found out it is deactivated in the code to "handle some bug". We
>> > would use scripts much more often , but they are currently not useful for
>> massive load tests (but for setup). For example we often manipulate JSON input
>> for REST requests.
>>
>> So why not convert the Groovy script to a Java test element?
>>
> Because it is a new plugin which gets to be deployed with every change to all
> computers producing the load. Scripts are easy to change and mustn't deployed
> (it's done by JMeter automatically).
>
>> > * or bundle groovy which seems to allow caching
>>
>> Including Groovy in the JMeter download won't change the behaviour from
>> downloading it separately.
>> In both cases the jar is present in the classpath; how can that affect caching?
>>
> I'm not sure how could you know the code about JSR223TestElement is implementing
> the support for "script compilation caching", so here comes some short code:
>
> processFileOrScript()
> // Hack as in bsh-2.0b5.jar BshScriptEngine implements Compilable but throws new Error
> boolean supportsCompilable = scriptEngine instanceof Compilable
> && !(scriptEngine.getClass().getName().equals("bsh.engine.BshScriptEngine"));
>
> Because the JavaScriptEngine is based on the BshScriptEngine the "script compilation caching"
> isn't available for Java, but it is available for groovy.
Which JavaScriptEngine?
> And therefore a (pre)compiled script does not load any classes (but in the very first step), then
> there is no synchronization with each call anymore.
>
> Is that understandable?
>
> I'm not saying "you must install groovy" , I just want to be sure having a scripting engine
> with "script compilation caching" working (or without any synchronization during runtime).
Script compilation is already possible - just download and use Groovy
or another Compilable scripting language.
What I am saying is that there is no need to include Groovy in the
JMeter binary release.
It works just as well if it is downloaded separately.
And if the BSH Compilable bug can be fixed, users could then use BeanShell.
> Greetings Danny
>
AW: Groovy
Posted by Danny Lade <D....@bigpoint.net>.
> > For the "groovy thing":
> > I would really wish to have scripts that are cached. But currently (using 2.9) this
> functionality can't be used for Java or beanshell.
> > As I found out it is deactivated in the code to "handle some bug". We
> > would use scripts much more often , but they are currently not useful for
> massive load tests (but for setup). For example we often manipulate JSON input
> for REST requests.
>
> So why not convert the Groovy script to a Java test element?
>
Because it is a new plugin which gets to be deployed with every change to all
computers producing the load. Scripts are easy to change and mustn't deployed
(it's done by JMeter automatically).
> > * or bundle groovy which seems to allow caching
>
> Including Groovy in the JMeter download won't change the behaviour from
> downloading it separately.
> In both cases the jar is present in the classpath; how can that affect caching?
>
I'm not sure how could you know the code about JSR223TestElement is implementing
the support for "script compilation caching", so here comes some short code:
processFileOrScript()
// Hack as in bsh-2.0b5.jar BshScriptEngine implements Compilable but throws new Error
boolean supportsCompilable = scriptEngine instanceof Compilable
&& !(scriptEngine.getClass().getName().equals("bsh.engine.BshScriptEngine"));
Because the JavaScriptEngine is based on the BshScriptEngine the "script compilation caching"
isn't available for Java, but it is available for groovy.
And therefore a (pre)compiled script does not load any classes (but in the very first step), then
there is no synchronization with each call anymore.
Is that understandable?
I'm not saying "you must install groovy" , I just want to be sure having a scripting engine
with "script compilation caching" working (or without any synchronization during runtime).
Greetings Danny
Re: Groovy
Posted by sebb <se...@gmail.com>.
On 3 July 2013 09:29, Danny Lade <D....@bigpoint.net> wrote:
> Just an idea:
> What about some kind of additional bundle one can install if he want to?
> So you wouldn't have to decide what you bundle with JMeter but can deliver an easy way for customers to add plugins if they like.
>
> For the "groovy thing":
> I would really wish to have scripts that are cached. But currently (using 2.9) this functionality can't be used for Java or beanshell.
> As I found out it is deactivated in the code to "handle some bug". We would use scripts much more often , but they are currently
> not useful for massive load tests (but for setup). For example we often manipulate JSON input for REST requests.
So why not convert the Groovy script to a Java test element?
> An investigation showed:
> Each script is loading classes from classpath during runtime which is synchronized over all threads - a huge lack of performance.
Only the first time a class is loaded; not sure that can be avoided,
though of course you can "warm up" your test by running a few threads
first before adding the main load.
>
> So IMO there are two ways:
> * either solve the problems caching scripts at all
If possible, that would the the way to go.
> * or bundle groovy which seems to allow caching
Including Groovy in the JMeter download won't change the behaviour
from downloading it separately.
In both cases the jar is present in the classpath; how can that affect caching?
> JM2C Danny
>
>> -----Ursprüngliche Nachricht-----
>> Von: Philippe Mouawad [mailto:philippe.mouawad@gmail.com]
>> Gesendet: Mittwoch, 3. Juli 2013 08:23
>> An: dev@jmeter.apache.org
>> Betreff: Re: Groovy
>>
>> In my experience Scripting elements are more than intended for prototyping .
>> In my 10 last recent scripting experience I have used them at least once. I have
>> met plenty of cases where you absolutely need them ( or you need to setup an
>> eclipse project with jmeter dependencies to finally generate a jar, I am sure
>> plenty of testers wouldn't do it).
>> I also feel it is one of JMeter best feature and gives it a real flexibility.
>>
>> With compilable they have nearly as good performance as if a jar had been
>> created with java classes.
>>
>> For the argument about having more jars in classpath, the perf loss is really very
>> tiny and most of it at startup and on class load.
>> And I feel it goes against reusing in that case.
>>
>> As for beanshell, ok but I think it will take some time before having the level of
>> features that groovy has.
>>
>> Regards
>> Philippe
>>
>> On Wednesday, July 3, 2013, Shmuel Krakower wrote:
>>
>> > Maybe scripting elements are intended for prototyping but from my
>> > experience I endup using few with most of the test plans I create, as
>> > I always miss some specific functionality, which can be answered by
>> > those script elements.
>> >
>> > Btw - what was the need when it was decided to add bean shell jars to
>> > jmeter?
>> >
>> > I am not for adding groovy or against.
>> > On Jul 3, 2013 1:49 AM, "sebb" <sebbaz@gmail.com <javascript:;>> wrote:
>> >
>> > > On 2 July 2013 23:26, Philippe Mouawad
>> > > <philippe.mouawad@gmail.com<javascript:;>>
>> > wrote:
>> > > > On Wednesday, July 3, 2013, sebb wrote:
>> > > >
>> > > >> On 2 July 2013 22:43, Philippe Mouawad
>> > > >> <philippe.mouawad@gmail.com<javascript:;>
>> > > <javascript:;>>
>> > > >> wrote:
>> > > >> > hello,
>> > > >> > so we include it ?
>> > > >> >
>> > > >> > It's +1 for me:
>> > > >> > - faster than beanshell
>> > > >> > - maintaned and jdk6 syntax can be used
>> > > >> > - big community
>> > > >>
>> > > >> None of the above require it to be bundled with JMeter.
>> > > >>
>> > > >> > - embedding it will encourage its usage
>> > > >>
>> > > >> Possibly; I'm not convinced it's necessary to include it.
>> > > >>
>> > > >> I think we need to be very careful about adding stuff to JMeter
>> > > >> just because it may be useful to some users. It's all to easy to
>> > > >> end up with a bloated product that performs poorly.
>> > > >>
>> > > >> on the contrary, adding it will encourage groovy usage instead of
>> > > > beanshell , and this will give better performances.
>> > >
>> > > Only for test plans that use scripting, but having more jars in the
>> > > classpath can have an adverse effect on all tests.
>> > >
>> > > Besides, the scripting test elements are primarily intended for
>> > > prototyping.
>> > >
>> > > Furthermore, BeanShell is hopefully joining Apache Commons soon.
>> > > It may well end up as fast or faster than Groovy.
>> > >
>> > > >> > Regards
>> > > >> > Philippe
>> > > >> >
>> > > >> > On Sunday, June 30, 2013, Philippe Mouawad wrote:
>> > > >> >
>> > > >> >> Hello Sebb,
>> > > >> >> It's Apache 2 license
>> > > >> >> groovy-all.jar is around 6m
>> > > >> >>
>> > > >> >> Regards
>> > > >> >> Philippe
>> > > >> >> On Sun, Jun 30, 2013 at 3:41 PM, sebb
>> > > >> >> <sebbaz@gmail.com<javascript:;>
>> > <javascript:;><javascript:_e({},
>> > > >> 'cvml', 'sebbaz@gmail.com <javascript:;> <javascript:;>');>
>> > > >> >> > wrote:
>> > > >> >>
>> > > >> >>> On 29 June 2013 22:57, Philippe Mouawad <
>> > philippe.mouawad@gmail.com <javascript:;>
>> > > <javascript:;><javascript:_e({},
>> > > >> 'cvml', 'philippe.mouawad@gmail.com
>> > > >> <javascript:;><javascript:;>');>>
>> > > >> >>> wrote:
>> > > >> >>> > Hello,
>> > > >> >>> > what about embedding groovy in next release so that it is
>> > > >> automatically
>> > > >> >>> > available to JSR223 sampler ?
>> > > >> >>>
>> > > >> >>> How big is it?
>> > > >> >>> What is the license?
>> > > >> >>>
>> > > >> >>> >
>> > > >> >>> >
>> > > >> >>> > Regards
>> > > >> >>> > Philippe
>> > > >> >>> >
>> > > >> >>> > --
>> > > >> >>> > Cordialement.
>> > > >> >>> > Philippe Mouawad.
>> > > >> >>>
>> > > >> >>
>> > > >> >>
>> > > >> >>
>> > > >> >> --
>> > > >> >> Cordialement.
>> > > >> >> Philippe Mouawad.
>> > > >> >>
>> > > >> >>
>> > > >> >>
>> > > >> >
>> > > >> > --
>> > > >> > Cordialement.
>> > > >> > Philippe Mouawad.
>> > > >>
>> > > >
>> > > >
>> > > > --
>> > > > Cordialement.
>> > > > Philippe Mouawad.
>> > >
>> >
>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.
AW: Groovy
Posted by Danny Lade <D....@bigpoint.net>.
Just an idea:
What about some kind of additional bundle one can install if he want to?
So you wouldn't have to decide what you bundle with JMeter but can deliver an easy way for customers to add plugins if they like.
For the "groovy thing":
I would really wish to have scripts that are cached. But currently (using 2.9) this functionality can't be used for Java or beanshell.
As I found out it is deactivated in the code to "handle some bug". We would use scripts much more often , but they are currently
not useful for massive load tests (but for setup). For example we often manipulate JSON input for REST requests.
An investigation showed:
Each script is loading classes from classpath during runtime which is synchronized over all threads - a huge lack of performance.
So IMO there are two ways:
* either solve the problems caching scripts at all
* or bundle groovy which seems to allow caching
JM2C Danny
> -----Ursprüngliche Nachricht-----
> Von: Philippe Mouawad [mailto:philippe.mouawad@gmail.com]
> Gesendet: Mittwoch, 3. Juli 2013 08:23
> An: dev@jmeter.apache.org
> Betreff: Re: Groovy
>
> In my experience Scripting elements are more than intended for prototyping .
> In my 10 last recent scripting experience I have used them at least once. I have
> met plenty of cases where you absolutely need them ( or you need to setup an
> eclipse project with jmeter dependencies to finally generate a jar, I am sure
> plenty of testers wouldn't do it).
> I also feel it is one of JMeter best feature and gives it a real flexibility.
>
> With compilable they have nearly as good performance as if a jar had been
> created with java classes.
>
> For the argument about having more jars in classpath, the perf loss is really very
> tiny and most of it at startup and on class load.
> And I feel it goes against reusing in that case.
>
> As for beanshell, ok but I think it will take some time before having the level of
> features that groovy has.
>
> Regards
> Philippe
>
> On Wednesday, July 3, 2013, Shmuel Krakower wrote:
>
> > Maybe scripting elements are intended for prototyping but from my
> > experience I endup using few with most of the test plans I create, as
> > I always miss some specific functionality, which can be answered by
> > those script elements.
> >
> > Btw - what was the need when it was decided to add bean shell jars to
> > jmeter?
> >
> > I am not for adding groovy or against.
> > On Jul 3, 2013 1:49 AM, "sebb" <sebbaz@gmail.com <javascript:;>> wrote:
> >
> > > On 2 July 2013 23:26, Philippe Mouawad
> > > <philippe.mouawad@gmail.com<javascript:;>>
> > wrote:
> > > > On Wednesday, July 3, 2013, sebb wrote:
> > > >
> > > >> On 2 July 2013 22:43, Philippe Mouawad
> > > >> <philippe.mouawad@gmail.com<javascript:;>
> > > <javascript:;>>
> > > >> wrote:
> > > >> > hello,
> > > >> > so we include it ?
> > > >> >
> > > >> > It's +1 for me:
> > > >> > - faster than beanshell
> > > >> > - maintaned and jdk6 syntax can be used
> > > >> > - big community
> > > >>
> > > >> None of the above require it to be bundled with JMeter.
> > > >>
> > > >> > - embedding it will encourage its usage
> > > >>
> > > >> Possibly; I'm not convinced it's necessary to include it.
> > > >>
> > > >> I think we need to be very careful about adding stuff to JMeter
> > > >> just because it may be useful to some users. It's all to easy to
> > > >> end up with a bloated product that performs poorly.
> > > >>
> > > >> on the contrary, adding it will encourage groovy usage instead of
> > > > beanshell , and this will give better performances.
> > >
> > > Only for test plans that use scripting, but having more jars in the
> > > classpath can have an adverse effect on all tests.
> > >
> > > Besides, the scripting test elements are primarily intended for
> > > prototyping.
> > >
> > > Furthermore, BeanShell is hopefully joining Apache Commons soon.
> > > It may well end up as fast or faster than Groovy.
> > >
> > > >> > Regards
> > > >> > Philippe
> > > >> >
> > > >> > On Sunday, June 30, 2013, Philippe Mouawad wrote:
> > > >> >
> > > >> >> Hello Sebb,
> > > >> >> It's Apache 2 license
> > > >> >> groovy-all.jar is around 6m
> > > >> >>
> > > >> >> Regards
> > > >> >> Philippe
> > > >> >> On Sun, Jun 30, 2013 at 3:41 PM, sebb
> > > >> >> <sebbaz@gmail.com<javascript:;>
> > <javascript:;><javascript:_e({},
> > > >> 'cvml', 'sebbaz@gmail.com <javascript:;> <javascript:;>');>
> > > >> >> > wrote:
> > > >> >>
> > > >> >>> On 29 June 2013 22:57, Philippe Mouawad <
> > philippe.mouawad@gmail.com <javascript:;>
> > > <javascript:;><javascript:_e({},
> > > >> 'cvml', 'philippe.mouawad@gmail.com
> > > >> <javascript:;><javascript:;>');>>
> > > >> >>> wrote:
> > > >> >>> > Hello,
> > > >> >>> > what about embedding groovy in next release so that it is
> > > >> automatically
> > > >> >>> > available to JSR223 sampler ?
> > > >> >>>
> > > >> >>> How big is it?
> > > >> >>> What is the license?
> > > >> >>>
> > > >> >>> >
> > > >> >>> >
> > > >> >>> > Regards
> > > >> >>> > Philippe
> > > >> >>> >
> > > >> >>> > --
> > > >> >>> > Cordialement.
> > > >> >>> > Philippe Mouawad.
> > > >> >>>
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> --
> > > >> >> Cordialement.
> > > >> >> Philippe Mouawad.
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >
> > > >> > --
> > > >> > Cordialement.
> > > >> > Philippe Mouawad.
> > > >>
> > > >
> > > >
> > > > --
> > > > Cordialement.
> > > > Philippe Mouawad.
> > >
> >
>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: Groovy
Posted by Philippe Mouawad <ph...@gmail.com>.
In my experience Scripting elements are more than intended for prototyping .
In my 10 last recent scripting experience I have used them at least once. I
have met plenty of cases where you absolutely need them ( or you need to
setup an eclipse project with jmeter dependencies to finally generate a
jar, I am sure plenty of testers wouldn't do it).
I also feel it is one of JMeter best feature and gives it a real
flexibility.
With compilable they have nearly as good performance as if a jar had been
created with java classes.
For the argument about having more jars in classpath, the perf loss is
really very tiny and most of it at startup and on class load.
And I feel it goes against reusing in that case.
As for beanshell, ok but I think it will take some time before having the
level of features that groovy has.
Regards
Philippe
On Wednesday, July 3, 2013, Shmuel Krakower wrote:
> Maybe scripting elements are intended for prototyping but from my
> experience I endup using few with most of the test plans I create, as I
> always miss some specific functionality, which can be answered by those
> script elements.
>
> Btw - what was the need when it was decided to add bean shell jars to
> jmeter?
>
> I am not for adding groovy or against.
> On Jul 3, 2013 1:49 AM, "sebb" <sebbaz@gmail.com <javascript:;>> wrote:
>
> > On 2 July 2013 23:26, Philippe Mouawad <philippe.mouawad@gmail.com<javascript:;>>
> wrote:
> > > On Wednesday, July 3, 2013, sebb wrote:
> > >
> > >> On 2 July 2013 22:43, Philippe Mouawad <philippe.mouawad@gmail.com<javascript:;>
> > <javascript:;>>
> > >> wrote:
> > >> > hello,
> > >> > so we include it ?
> > >> >
> > >> > It's +1 for me:
> > >> > - faster than beanshell
> > >> > - maintaned and jdk6 syntax can be used
> > >> > - big community
> > >>
> > >> None of the above require it to be bundled with JMeter.
> > >>
> > >> > - embedding it will encourage its usage
> > >>
> > >> Possibly; I'm not convinced it's necessary to include it.
> > >>
> > >> I think we need to be very careful about adding stuff to JMeter just
> > >> because it may be useful to some users. It's all to easy to end up
> > >> with a bloated product that performs poorly.
> > >>
> > >> on the contrary, adding it will encourage groovy usage instead of
> > > beanshell , and this will give better performances.
> >
> > Only for test plans that use scripting, but having more jars in the
> > classpath can have an adverse effect on all tests.
> >
> > Besides, the scripting test elements are primarily intended for
> > prototyping.
> >
> > Furthermore, BeanShell is hopefully joining Apache Commons soon.
> > It may well end up as fast or faster than Groovy.
> >
> > >> > Regards
> > >> > Philippe
> > >> >
> > >> > On Sunday, June 30, 2013, Philippe Mouawad wrote:
> > >> >
> > >> >> Hello Sebb,
> > >> >> It's Apache 2 license
> > >> >> groovy-all.jar is around 6m
> > >> >>
> > >> >> Regards
> > >> >> Philippe
> > >> >> On Sun, Jun 30, 2013 at 3:41 PM, sebb <sebbaz@gmail.com<javascript:;>
> <javascript:;><javascript:_e({},
> > >> 'cvml', 'sebbaz@gmail.com <javascript:;> <javascript:;>');>
> > >> >> > wrote:
> > >> >>
> > >> >>> On 29 June 2013 22:57, Philippe Mouawad <
> philippe.mouawad@gmail.com <javascript:;>
> > <javascript:;><javascript:_e({},
> > >> 'cvml', 'philippe.mouawad@gmail.com <javascript:;><javascript:;>');>>
> > >> >>> wrote:
> > >> >>> > Hello,
> > >> >>> > what about embedding groovy in next release so that it is
> > >> automatically
> > >> >>> > available to JSR223 sampler ?
> > >> >>>
> > >> >>> How big is it?
> > >> >>> What is the license?
> > >> >>>
> > >> >>> >
> > >> >>> >
> > >> >>> > Regards
> > >> >>> > Philippe
> > >> >>> >
> > >> >>> > --
> > >> >>> > Cordialement.
> > >> >>> > Philippe Mouawad.
> > >> >>>
> > >> >>
> > >> >>
> > >> >>
> > >> >> --
> > >> >> Cordialement.
> > >> >> Philippe Mouawad.
> > >> >>
> > >> >>
> > >> >>
> > >> >
> > >> > --
> > >> > Cordialement.
> > >> > Philippe Mouawad.
> > >>
> > >
> > >
> > > --
> > > Cordialement.
> > > Philippe Mouawad.
> >
>
--
Cordialement.
Philippe Mouawad.
Re: Groovy
Posted by Shmuel Krakower <sh...@gmail.com>.
Maybe scripting elements are intended for prototyping but from my
experience I endup using few with most of the test plans I create, as I
always miss some specific functionality, which can be answered by those
script elements.
Btw - what was the need when it was decided to add bean shell jars to
jmeter?
I am not for adding groovy or against.
On Jul 3, 2013 1:49 AM, "sebb" <se...@gmail.com> wrote:
> On 2 July 2013 23:26, Philippe Mouawad <ph...@gmail.com> wrote:
> > On Wednesday, July 3, 2013, sebb wrote:
> >
> >> On 2 July 2013 22:43, Philippe Mouawad <philippe.mouawad@gmail.com
> <javascript:;>>
> >> wrote:
> >> > hello,
> >> > so we include it ?
> >> >
> >> > It's +1 for me:
> >> > - faster than beanshell
> >> > - maintaned and jdk6 syntax can be used
> >> > - big community
> >>
> >> None of the above require it to be bundled with JMeter.
> >>
> >> > - embedding it will encourage its usage
> >>
> >> Possibly; I'm not convinced it's necessary to include it.
> >>
> >> I think we need to be very careful about adding stuff to JMeter just
> >> because it may be useful to some users. It's all to easy to end up
> >> with a bloated product that performs poorly.
> >>
> >> on the contrary, adding it will encourage groovy usage instead of
> > beanshell , and this will give better performances.
>
> Only for test plans that use scripting, but having more jars in the
> classpath can have an adverse effect on all tests.
>
> Besides, the scripting test elements are primarily intended for
> prototyping.
>
> Furthermore, BeanShell is hopefully joining Apache Commons soon.
> It may well end up as fast or faster than Groovy.
>
> >> > Regards
> >> > Philippe
> >> >
> >> > On Sunday, June 30, 2013, Philippe Mouawad wrote:
> >> >
> >> >> Hello Sebb,
> >> >> It's Apache 2 license
> >> >> groovy-all.jar is around 6m
> >> >>
> >> >> Regards
> >> >> Philippe
> >> >> On Sun, Jun 30, 2013 at 3:41 PM, sebb <sebbaz@gmail.com<javascript:;><javascript:_e({},
> >> 'cvml', 'sebbaz@gmail.com <javascript:;>');>
> >> >> > wrote:
> >> >>
> >> >>> On 29 June 2013 22:57, Philippe Mouawad <philippe.mouawad@gmail.com
> <javascript:;><javascript:_e({},
> >> 'cvml', 'philippe.mouawad@gmail.com <javascript:;>');>>
> >> >>> wrote:
> >> >>> > Hello,
> >> >>> > what about embedding groovy in next release so that it is
> >> automatically
> >> >>> > available to JSR223 sampler ?
> >> >>>
> >> >>> How big is it?
> >> >>> What is the license?
> >> >>>
> >> >>> >
> >> >>> >
> >> >>> > Regards
> >> >>> > Philippe
> >> >>> >
> >> >>> > --
> >> >>> > Cordialement.
> >> >>> > Philippe Mouawad.
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Cordialement.
> >> >> Philippe Mouawad.
> >> >>
> >> >>
> >> >>
> >> >
> >> > --
> >> > Cordialement.
> >> > Philippe Mouawad.
> >>
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>
Re: Groovy
Posted by sebb <se...@gmail.com>.
On 2 July 2013 23:26, Philippe Mouawad <ph...@gmail.com> wrote:
> On Wednesday, July 3, 2013, sebb wrote:
>
>> On 2 July 2013 22:43, Philippe Mouawad <philippe.mouawad@gmail.com<javascript:;>>
>> wrote:
>> > hello,
>> > so we include it ?
>> >
>> > It's +1 for me:
>> > - faster than beanshell
>> > - maintaned and jdk6 syntax can be used
>> > - big community
>>
>> None of the above require it to be bundled with JMeter.
>>
>> > - embedding it will encourage its usage
>>
>> Possibly; I'm not convinced it's necessary to include it.
>>
>> I think we need to be very careful about adding stuff to JMeter just
>> because it may be useful to some users. It's all to easy to end up
>> with a bloated product that performs poorly.
>>
>> on the contrary, adding it will encourage groovy usage instead of
> beanshell , and this will give better performances.
Only for test plans that use scripting, but having more jars in the
classpath can have an adverse effect on all tests.
Besides, the scripting test elements are primarily intended for prototyping.
Furthermore, BeanShell is hopefully joining Apache Commons soon.
It may well end up as fast or faster than Groovy.
>> > Regards
>> > Philippe
>> >
>> > On Sunday, June 30, 2013, Philippe Mouawad wrote:
>> >
>> >> Hello Sebb,
>> >> It's Apache 2 license
>> >> groovy-all.jar is around 6m
>> >>
>> >> Regards
>> >> Philippe
>> >> On Sun, Jun 30, 2013 at 3:41 PM, sebb <sebbaz@gmail.com <javascript:;><javascript:_e({},
>> 'cvml', 'sebbaz@gmail.com <javascript:;>');>
>> >> > wrote:
>> >>
>> >>> On 29 June 2013 22:57, Philippe Mouawad <philippe.mouawad@gmail.com<javascript:;><javascript:_e({},
>> 'cvml', 'philippe.mouawad@gmail.com <javascript:;>');>>
>> >>> wrote:
>> >>> > Hello,
>> >>> > what about embedding groovy in next release so that it is
>> automatically
>> >>> > available to JSR223 sampler ?
>> >>>
>> >>> How big is it?
>> >>> What is the license?
>> >>>
>> >>> >
>> >>> >
>> >>> > Regards
>> >>> > Philippe
>> >>> >
>> >>> > --
>> >>> > Cordialement.
>> >>> > Philippe Mouawad.
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Cordialement.
>> >> Philippe Mouawad.
>> >>
>> >>
>> >>
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: Groovy
Posted by Philippe Mouawad <ph...@gmail.com>.
On Wednesday, July 3, 2013, sebb wrote:
> On 2 July 2013 22:43, Philippe Mouawad <philippe.mouawad@gmail.com<javascript:;>>
> wrote:
> > hello,
> > so we include it ?
> >
> > It's +1 for me:
> > - faster than beanshell
> > - maintaned and jdk6 syntax can be used
> > - big community
>
> None of the above require it to be bundled with JMeter.
>
> > - embedding it will encourage its usage
>
> Possibly; I'm not convinced it's necessary to include it.
>
> I think we need to be very careful about adding stuff to JMeter just
> because it may be useful to some users. It's all to easy to end up
> with a bloated product that performs poorly.
>
> on the contrary, adding it will encourage groovy usage instead of
beanshell , and this will give better performances.
> > Regards
> > Philippe
> >
> > On Sunday, June 30, 2013, Philippe Mouawad wrote:
> >
> >> Hello Sebb,
> >> It's Apache 2 license
> >> groovy-all.jar is around 6m
> >>
> >> Regards
> >> Philippe
> >> On Sun, Jun 30, 2013 at 3:41 PM, sebb <sebbaz@gmail.com <javascript:;><javascript:_e({},
> 'cvml', 'sebbaz@gmail.com <javascript:;>');>
> >> > wrote:
> >>
> >>> On 29 June 2013 22:57, Philippe Mouawad <philippe.mouawad@gmail.com<javascript:;><javascript:_e({},
> 'cvml', 'philippe.mouawad@gmail.com <javascript:;>');>>
> >>> wrote:
> >>> > Hello,
> >>> > what about embedding groovy in next release so that it is
> automatically
> >>> > available to JSR223 sampler ?
> >>>
> >>> How big is it?
> >>> What is the license?
> >>>
> >>> >
> >>> >
> >>> > Regards
> >>> > Philippe
> >>> >
> >>> > --
> >>> > Cordialement.
> >>> > Philippe Mouawad.
> >>>
> >>
> >>
> >>
> >> --
> >> Cordialement.
> >> Philippe Mouawad.
> >>
> >>
> >>
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>
--
Cordialement.
Philippe Mouawad.
Re: Groovy
Posted by sebb <se...@gmail.com>.
On 2 July 2013 22:43, Philippe Mouawad <ph...@gmail.com> wrote:
> hello,
> so we include it ?
>
> It's +1 for me:
> - faster than beanshell
> - maintaned and jdk6 syntax can be used
> - big community
None of the above require it to be bundled with JMeter.
> - embedding it will encourage its usage
Possibly; I'm not convinced it's necessary to include it.
I think we need to be very careful about adding stuff to JMeter just
because it may be useful to some users. It's all to easy to end up
with a bloated product that performs poorly.
> Regards
> Philippe
>
> On Sunday, June 30, 2013, Philippe Mouawad wrote:
>
>> Hello Sebb,
>> It's Apache 2 license
>> groovy-all.jar is around 6m
>>
>> Regards
>> Philippe
>> On Sun, Jun 30, 2013 at 3:41 PM, sebb <sebbaz@gmail.com<javascript:_e({}, 'cvml', 'sebbaz@gmail.com');>
>> > wrote:
>>
>>> On 29 June 2013 22:57, Philippe Mouawad <philippe.mouawad@gmail.com<javascript:_e({}, 'cvml', 'philippe.mouawad@gmail.com');>>
>>> wrote:
>>> > Hello,
>>> > what about embedding groovy in next release so that it is automatically
>>> > available to JSR223 sampler ?
>>>
>>> How big is it?
>>> What is the license?
>>>
>>> >
>>> >
>>> > Regards
>>> > Philippe
>>> >
>>> > --
>>> > Cordialement.
>>> > Philippe Mouawad.
>>>
>>
>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.
>>
>>
>>
>
> --
> Cordialement.
> Philippe Mouawad.