You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Keith Young <yo...@gmail.com> on 2013/01/08 15:49:26 UTC
Re: PERFORMANCE => Changing JMeter defaults to ensure better
performances by default
>> Encourage JSR223 Samplers + Groovy + Caching instead of Beanshell
Can someone point me to some documentation that outlines this better? If I
include a JSR223 sampler there is no option for Groovy. The wiki link in
this message thread says to include groovy-VERSION-all.jar in the
jmeter/bin directory, but a download of Groovy 2.0.6 doesn't have that jar.
Is the groovy-2.0.6.jar enough?
What caching is the above point referring to?
Sorry for these questions on the dev list, but that's where this thread
is... :)
Cheers,
Keith.
On 27 December 2012 05:06, Milamber <mi...@apache.org> wrote:
>
>
> Le 24/12/2012 13:20, Philippe Mouawad a ecrit :
>
> Hello,
>>
>> I am kind of annoyed of reading articles, blogs that say JMeter cannot
>> perform high Load Tests, consumes lot of memory, generates OutOfMemory ...
>>
>> This has become a kind of "Urban Legend" partly due:
>> - to issues that have been fixed for a while now
>> - and partly In my opinion to some default configuration parameters that
>> lead to these issues
>>
>> In my opinion, we should:
>>
>> 1) change these defaults to avoid new comers, beginners fall into all
>> these
>> traps and others check they are using it well:
>>
>> - Save Service using XML output => Change to CSV
>>
>
> Yes, CSV seems a better default type to the results file.
>
>
> - Distributed Mode that uses the Standard which is far from being the
>> best performing Sample Sender => Change to Batch or StrippedBatch
>>
>
> Why Batch ou StrippedBatch ? Why not Asynch or Diskstore?
>
>
>
>> 2) Add warnings on GUIs of all elements that are more suited during
>> Scripting than during Load Test :
>>
>> - View Result Tree (I keep seeing people use this element during High
>> Load Test ! )
>> - View Results in Table
>> - Graph Results
>> - ...
>>
>
> JMeter can be used for functional tests. Warnings on GUI for the 'heavy'
> elements can be unpleasant.
>
> Perhaps add a menu/button option "Check script for load test" which
> display some warning (in a box or another way) when heavy elements are
> found in the tree.
> This option can be enabled by a property to checked before every load tests
>
>
> 3) Add a popup warning when Start and Remote Start are clicked from GUI to
>> encourage NON GUI mode use (we could add a checkbox Remind Me later which
>> could be unchecked to avoid it again, but at least user would know about
>> it).
>>
>
> See comment in 2)
>
>
>
>
> 4) Finally use some kind of visual indicator (RED background) on some
>> options that have high impact on performance:
>>
>> - Javascript as scripting language
>> - Body (unescaped) in Regular Expression Extractor (*this one is a
>> real
>> performance killer !*)
>> - Encourage JSR223 Samplers + Groovy + Caching instead of Beanshell
>> - ...
>>
>
> point 2) too
> The "check script for load test" wizard can displaying warnings for this
> elements, and give some tips for performance
>
>
>
>> Maybe we should post this mail on user mailing list to see what users
>> think
>> about it.
>>
>>
>
Re: PERFORMANCE => Changing JMeter defaults to ensure better
performances by default
Posted by Philippe Mouawad <ph...@gmail.com>.
Hello sebb
My question was about the initial question:
- changing the jmeter defaults
...
Regards
Philippe
On Thursday, January 10, 2013, sebb wrote:
> On 9 January 2013 22:03, Philippe Mouawad <philippe.mouawad@gmail.com<javascript:;>>
> wrote:
> > Hello,
> > Sebb What's your opinion on this ?
>
> If the wiki is wrong about the groovy jar name, just fix it?
>
> > Regards
> > Philippe
> >
> > On Tuesday, January 8, 2013, Keith Young wrote:
> >
> >> Ahh... found it... you might want to update the wiki text...
> >>
> >> from:
> >> groovy-VERSION-all.jar
> >> to:
> >> groovy-all-VERSION.jar
> >>
> >> Thanks!
> >>
> >> Cheers,
> >> Keith.
> >>
> >>
> >> On 8 January 2013 10:26, Philippe Mouawad <philippe.mouawad@gmail.com<javascript:;>
> <javascript:;>
> >> >wrote:
> >>
> >> > Hello,
> >> > The groovy-all.jar in in *embeddable* folder of the
> >> groovy-binary-2.0.6.zip
> >> > file.
> >> >
> >> > Once you add it in jmeter/lib folder, restart jmeter and groovy will
> >> > appear.
> >> > I will do some autopromotion :-) , see this for what will be
> available in
> >> > JMeter 2.9 (part of it is in 2.8):
> >> >
> >> > -
> >> >
> >> >
> >>
> http://www.ubik-ingenierie.com/blog/jmeter_control_percentage_of_sampler/
> >> >
> >> >
> >> > If you want to test, you can get nightly build (but read warning and
> >> > install instructions):
> >> >
> >> > - http://jmeter.apache.org/nightly.html
> >> >
> >> > Regards
> >> >
> >> > Philippe
> >> >
> >> > http://www.ubik-ingenierie.com/blog/
> >> > On Tue, Jan 8, 2013 at 3:49 PM, Keith Young <yo...@gmail.com>
> wrote:
> >> >
> >> > > >> Encourage JSR223 Samplers + Groovy + Caching instead of
> Beanshell
> >> > >
> >> > > Can someone point me to some documentation that outlines this
> better?
> >> > If I
> >> > > include a JSR223 sampler there is no option for Groovy. The wiki
> link
> >> in
> >> > > this message thread says to include groovy-VERSION-all.jar in the
> >> > > jmeter/bin directory, but a download of Groovy 2.0.6 doesn't have
> that
> >> > jar.
> >> > > Is the groovy-2.0.6.jar enough?
> >> > >
> >> > > What caching is the above point referring to?
> >> > >
> >> > > Sorry for these questions on the dev list, but that's where this
> thread
> >> > > is... :)
> >> > >
> >> > > Cheers,
> >> > > Keith.
> >> > >
> >> > >
> >> > > On 27 December 2012 05:06, Milamber <mi...@apache.org> wrote:
> >> > >
> >> > > >
> >> > > >
> >> > > > Le 24/12/2012 13:20, Philippe Mouawad a ecrit :
> >> > > >
> >> > > > Hello,
> >> > > >>
> >> > > >> I am kind of annoyed of reading articles, blogs that say JMeter
> >> cannot
> >> > > >> perform high Load Tests, consumes lot of memory, generates
> >> OutOfMemory
> >> > > ...
> >> > > >>
> >> > > >> This has become a kind of "Urban Legend" partly due:
> >> > > >> - to issues that have been fixed for a while now
> >> > > >> - and partly In my opinion to some default configuration
> parameters
> >> > that
> >> > > >> lead to these issues
> >> > > >>
> >> > > >> In my opinion, we should:
> >> > > >>
> >> > > >> 1) change these defaults to avoid new comers, beginners fall into
> >> all
> >> > > >> these
> >> > > >> traps and others check they are using it well:
> >> > > >>
> >> > > >> - Save Service using XML output => Change to CSV
> >> > > >>
> >> > > >
> >> > > > Yes, CSV seems a better default type to the results file.
> >> > > >
> >> > > >
> >> > > > - Distributed Mode that uses the Standard which is far from
> >> being
> >> > > the
> >> > > >> best performing Sample Sender => Change to Batch or
> >> StrippedBatch
> >> > > >>
> >> > > >
> >> > > > Why Batch ou StrippedBatch ? Why not Asynch or Diskstore?
> >> > > >
> >> > > >
> >> > > >
> >> > > >> 2) Add warnings on GUIs of all elements that are more suited
> during
> >> > > >> Scri
--
Cordialement.
Philippe Mouawad.
Re: PERFORMANCE => Changing JMeter defaults to ensure better
performances by default
Posted by sebb <se...@gmail.com>.
On 9 January 2013 22:03, Philippe Mouawad <ph...@gmail.com> wrote:
> Hello,
> Sebb What's your opinion on this ?
If the wiki is wrong about the groovy jar name, just fix it?
> Regards
> Philippe
>
> On Tuesday, January 8, 2013, Keith Young wrote:
>
>> Ahh... found it... you might want to update the wiki text...
>>
>> from:
>> groovy-VERSION-all.jar
>> to:
>> groovy-all-VERSION.jar
>>
>> Thanks!
>>
>> Cheers,
>> Keith.
>>
>>
>> On 8 January 2013 10:26, Philippe Mouawad <philippe.mouawad@gmail.com<javascript:;>
>> >wrote:
>>
>> > Hello,
>> > The groovy-all.jar in in *embeddable* folder of the
>> groovy-binary-2.0.6.zip
>> > file.
>> >
>> > Once you add it in jmeter/lib folder, restart jmeter and groovy will
>> > appear.
>> > I will do some autopromotion :-) , see this for what will be available in
>> > JMeter 2.9 (part of it is in 2.8):
>> >
>> > -
>> >
>> >
>> http://www.ubik-ingenierie.com/blog/jmeter_control_percentage_of_sampler/
>> >
>> >
>> > If you want to test, you can get nightly build (but read warning and
>> > install instructions):
>> >
>> > - http://jmeter.apache.org/nightly.html
>> >
>> > Regards
>> >
>> > Philippe
>> >
>> > http://www.ubik-ingenierie.com/blog/
>> > On Tue, Jan 8, 2013 at 3:49 PM, Keith Young <yo...@gmail.com> wrote:
>> >
>> > > >> Encourage JSR223 Samplers + Groovy + Caching instead of Beanshell
>> > >
>> > > Can someone point me to some documentation that outlines this better?
>> > If I
>> > > include a JSR223 sampler there is no option for Groovy. The wiki link
>> in
>> > > this message thread says to include groovy-VERSION-all.jar in the
>> > > jmeter/bin directory, but a download of Groovy 2.0.6 doesn't have that
>> > jar.
>> > > Is the groovy-2.0.6.jar enough?
>> > >
>> > > What caching is the above point referring to?
>> > >
>> > > Sorry for these questions on the dev list, but that's where this thread
>> > > is... :)
>> > >
>> > > Cheers,
>> > > Keith.
>> > >
>> > >
>> > > On 27 December 2012 05:06, Milamber <mi...@apache.org> wrote:
>> > >
>> > > >
>> > > >
>> > > > Le 24/12/2012 13:20, Philippe Mouawad a ecrit :
>> > > >
>> > > > Hello,
>> > > >>
>> > > >> I am kind of annoyed of reading articles, blogs that say JMeter
>> cannot
>> > > >> perform high Load Tests, consumes lot of memory, generates
>> OutOfMemory
>> > > ...
>> > > >>
>> > > >> This has become a kind of "Urban Legend" partly due:
>> > > >> - to issues that have been fixed for a while now
>> > > >> - and partly In my opinion to some default configuration parameters
>> > that
>> > > >> lead to these issues
>> > > >>
>> > > >> In my opinion, we should:
>> > > >>
>> > > >> 1) change these defaults to avoid new comers, beginners fall into
>> all
>> > > >> these
>> > > >> traps and others check they are using it well:
>> > > >>
>> > > >> - Save Service using XML output => Change to CSV
>> > > >>
>> > > >
>> > > > Yes, CSV seems a better default type to the results file.
>> > > >
>> > > >
>> > > > - Distributed Mode that uses the Standard which is far from
>> being
>> > > the
>> > > >> best performing Sample Sender => Change to Batch or
>> StrippedBatch
>> > > >>
>> > > >
>> > > > Why Batch ou StrippedBatch ? Why not Asynch or Diskstore?
>> > > >
>> > > >
>> > > >
>> > > >> 2) Add warnings on GUIs of all elements that are more suited during
>> > > >> Scripting than during Load Test :
>> > > >>
>> > > >> - View Result Tree (I keep seeing people use this element during
>> > > High
>> > > >> Load Test ! )
>> > > >> - View Results in Table
>> > > >> - Graph Results
>> > > >> - ...
>> > > >>
>> > > >
>> > > > JMeter can be used for functional tests. Warnings on GUI for the
>> > 'heavy'
>> > > > elements can be unpleasant.
>> > > >
>> > > > Perhaps add a menu/button option "Check script for load test" which
>> > > > display some warning (in a box or another way) when heavy elements
>> are
>> > > > found in the tree.
>> > > > This option can be enabled by a property to checked before every load
>> > > tests
>> > > >
>> > > >
>> > > > 3) Add a popup warning when Start and Remote Start are clicked from
>> > GUI
>> > > to
>> > > >> encourage NON GUI mode use (we could add a checkbox Remind Me later
>> > > which
>> > > >> could be unchecked to avoid it again, but at least user would know
>> > about
>> > > >> it).
>> > > >>
>> > > >
>> > > > See comment in 2)
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > 4) Finally use some kind of visual indicator (RED background) on
>> some
>> > > >> options that have high impact on performance:
>> > > >>
>> > > >> - Javascript as scripting language
>> > >
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: PERFORMANCE => Changing JMeter defaults to ensure better
performances by default
Posted by Philippe Mouawad <ph...@gmail.com>.
Hello,
Sebb What's your opinion on this ?
Regards
Philippe
On Tuesday, January 8, 2013, Keith Young wrote:
> Ahh... found it... you might want to update the wiki text...
>
> from:
> groovy-VERSION-all.jar
> to:
> groovy-all-VERSION.jar
>
> Thanks!
>
> Cheers,
> Keith.
>
>
> On 8 January 2013 10:26, Philippe Mouawad <philippe.mouawad@gmail.com<javascript:;>
> >wrote:
>
> > Hello,
> > The groovy-all.jar in in *embeddable* folder of the
> groovy-binary-2.0.6.zip
> > file.
> >
> > Once you add it in jmeter/lib folder, restart jmeter and groovy will
> > appear.
> > I will do some autopromotion :-) , see this for what will be available in
> > JMeter 2.9 (part of it is in 2.8):
> >
> > -
> >
> >
> http://www.ubik-ingenierie.com/blog/jmeter_control_percentage_of_sampler/
> >
> >
> > If you want to test, you can get nightly build (but read warning and
> > install instructions):
> >
> > - http://jmeter.apache.org/nightly.html
> >
> > Regards
> >
> > Philippe
> >
> > http://www.ubik-ingenierie.com/blog/
> > On Tue, Jan 8, 2013 at 3:49 PM, Keith Young <yo...@gmail.com> wrote:
> >
> > > >> Encourage JSR223 Samplers + Groovy + Caching instead of Beanshell
> > >
> > > Can someone point me to some documentation that outlines this better?
> > If I
> > > include a JSR223 sampler there is no option for Groovy. The wiki link
> in
> > > this message thread says to include groovy-VERSION-all.jar in the
> > > jmeter/bin directory, but a download of Groovy 2.0.6 doesn't have that
> > jar.
> > > Is the groovy-2.0.6.jar enough?
> > >
> > > What caching is the above point referring to?
> > >
> > > Sorry for these questions on the dev list, but that's where this thread
> > > is... :)
> > >
> > > Cheers,
> > > Keith.
> > >
> > >
> > > On 27 December 2012 05:06, Milamber <mi...@apache.org> wrote:
> > >
> > > >
> > > >
> > > > Le 24/12/2012 13:20, Philippe Mouawad a ecrit :
> > > >
> > > > Hello,
> > > >>
> > > >> I am kind of annoyed of reading articles, blogs that say JMeter
> cannot
> > > >> perform high Load Tests, consumes lot of memory, generates
> OutOfMemory
> > > ...
> > > >>
> > > >> This has become a kind of "Urban Legend" partly due:
> > > >> - to issues that have been fixed for a while now
> > > >> - and partly In my opinion to some default configuration parameters
> > that
> > > >> lead to these issues
> > > >>
> > > >> In my opinion, we should:
> > > >>
> > > >> 1) change these defaults to avoid new comers, beginners fall into
> all
> > > >> these
> > > >> traps and others check they are using it well:
> > > >>
> > > >> - Save Service using XML output => Change to CSV
> > > >>
> > > >
> > > > Yes, CSV seems a better default type to the results file.
> > > >
> > > >
> > > > - Distributed Mode that uses the Standard which is far from
> being
> > > the
> > > >> best performing Sample Sender => Change to Batch or
> StrippedBatch
> > > >>
> > > >
> > > > Why Batch ou StrippedBatch ? Why not Asynch or Diskstore?
> > > >
> > > >
> > > >
> > > >> 2) Add warnings on GUIs of all elements that are more suited during
> > > >> Scripting than during Load Test :
> > > >>
> > > >> - View Result Tree (I keep seeing people use this element during
> > > High
> > > >> Load Test ! )
> > > >> - View Results in Table
> > > >> - Graph Results
> > > >> - ...
> > > >>
> > > >
> > > > JMeter can be used for functional tests. Warnings on GUI for the
> > 'heavy'
> > > > elements can be unpleasant.
> > > >
> > > > Perhaps add a menu/button option "Check script for load test" which
> > > > display some warning (in a box or another way) when heavy elements
> are
> > > > found in the tree.
> > > > This option can be enabled by a property to checked before every load
> > > tests
> > > >
> > > >
> > > > 3) Add a popup warning when Start and Remote Start are clicked from
> > GUI
> > > to
> > > >> encourage NON GUI mode use (we could add a checkbox Remind Me later
> > > which
> > > >> could be unchecked to avoid it again, but at least user would know
> > about
> > > >> it).
> > > >>
> > > >
> > > > See comment in 2)
> > > >
> > > >
> > > >
> > > >
> > > > 4) Finally use some kind of visual indicator (RED background) on
> some
> > > >> options that have high impact on performance:
> > > >>
> > > >> - Javascript as scripting language
> > >
--
Cordialement.
Philippe Mouawad.
Re: PERFORMANCE => Changing JMeter defaults to ensure better
performances by default
Posted by Keith Young <yo...@gmail.com>.
Ahh... found it... you might want to update the wiki text...
from:
groovy-VERSION-all.jar
to:
groovy-all-VERSION.jar
Thanks!
Cheers,
Keith.
On 8 January 2013 10:26, Philippe Mouawad <ph...@gmail.com>wrote:
> Hello,
> The groovy-all.jar in in *embeddable* folder of the groovy-binary-2.0.6.zip
> file.
>
> Once you add it in jmeter/lib folder, restart jmeter and groovy will
> appear.
> I will do some autopromotion :-) , see this for what will be available in
> JMeter 2.9 (part of it is in 2.8):
>
> -
>
> http://www.ubik-ingenierie.com/blog/jmeter_control_percentage_of_sampler/
>
>
> If you want to test, you can get nightly build (but read warning and
> install instructions):
>
> - http://jmeter.apache.org/nightly.html
>
> Regards
>
> Philippe
>
> http://www.ubik-ingenierie.com/blog/
> On Tue, Jan 8, 2013 at 3:49 PM, Keith Young <yo...@gmail.com> wrote:
>
> > >> Encourage JSR223 Samplers + Groovy + Caching instead of Beanshell
> >
> > Can someone point me to some documentation that outlines this better?
> If I
> > include a JSR223 sampler there is no option for Groovy. The wiki link in
> > this message thread says to include groovy-VERSION-all.jar in the
> > jmeter/bin directory, but a download of Groovy 2.0.6 doesn't have that
> jar.
> > Is the groovy-2.0.6.jar enough?
> >
> > What caching is the above point referring to?
> >
> > Sorry for these questions on the dev list, but that's where this thread
> > is... :)
> >
> > Cheers,
> > Keith.
> >
> >
> > On 27 December 2012 05:06, Milamber <mi...@apache.org> wrote:
> >
> > >
> > >
> > > Le 24/12/2012 13:20, Philippe Mouawad a ecrit :
> > >
> > > Hello,
> > >>
> > >> I am kind of annoyed of reading articles, blogs that say JMeter cannot
> > >> perform high Load Tests, consumes lot of memory, generates OutOfMemory
> > ...
> > >>
> > >> This has become a kind of "Urban Legend" partly due:
> > >> - to issues that have been fixed for a while now
> > >> - and partly In my opinion to some default configuration parameters
> that
> > >> lead to these issues
> > >>
> > >> In my opinion, we should:
> > >>
> > >> 1) change these defaults to avoid new comers, beginners fall into all
> > >> these
> > >> traps and others check they are using it well:
> > >>
> > >> - Save Service using XML output => Change to CSV
> > >>
> > >
> > > Yes, CSV seems a better default type to the results file.
> > >
> > >
> > > - Distributed Mode that uses the Standard which is far from being
> > the
> > >> best performing Sample Sender => Change to Batch or StrippedBatch
> > >>
> > >
> > > Why Batch ou StrippedBatch ? Why not Asynch or Diskstore?
> > >
> > >
> > >
> > >> 2) Add warnings on GUIs of all elements that are more suited during
> > >> Scripting than during Load Test :
> > >>
> > >> - View Result Tree (I keep seeing people use this element during
> > High
> > >> Load Test ! )
> > >> - View Results in Table
> > >> - Graph Results
> > >> - ...
> > >>
> > >
> > > JMeter can be used for functional tests. Warnings on GUI for the
> 'heavy'
> > > elements can be unpleasant.
> > >
> > > Perhaps add a menu/button option "Check script for load test" which
> > > display some warning (in a box or another way) when heavy elements are
> > > found in the tree.
> > > This option can be enabled by a property to checked before every load
> > tests
> > >
> > >
> > > 3) Add a popup warning when Start and Remote Start are clicked from
> GUI
> > to
> > >> encourage NON GUI mode use (we could add a checkbox Remind Me later
> > which
> > >> could be unchecked to avoid it again, but at least user would know
> about
> > >> it).
> > >>
> > >
> > > See comment in 2)
> > >
> > >
> > >
> > >
> > > 4) Finally use some kind of visual indicator (RED background) on some
> > >> options that have high impact on performance:
> > >>
> > >> - Javascript as scripting language
> > >> - Body (unescaped) in Regular Expression Extractor (*this one is a
> > >> real
> > >> performance killer !*)
> > >> - Encourage JSR223 Samplers + Groovy + Caching instead of
> Beanshell
> > >> - ...
> > >>
> > >
> > > point 2) too
> > > The "check script for load test" wizard can displaying warnings for
> this
> > > elements, and give some tips for performance
> > >
> > >
> > >
> > >> Maybe we should post this mail on user mailing list to see what users
> > >> think
> > >> about it.
> > >>
> > >>
> > >
> >
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
Re: PERFORMANCE => Changing JMeter defaults to ensure better
performances by default
Posted by Philippe Mouawad <ph...@gmail.com>.
Hello,
The groovy-all.jar in in *embeddable* folder of the groovy-binary-2.0.6.zip
file.
Once you add it in jmeter/lib folder, restart jmeter and groovy will appear.
I will do some autopromotion :-) , see this for what will be available in
JMeter 2.9 (part of it is in 2.8):
-
http://www.ubik-ingenierie.com/blog/jmeter_control_percentage_of_sampler/
If you want to test, you can get nightly build (but read warning and
install instructions):
- http://jmeter.apache.org/nightly.html
Regards
Philippe
http://www.ubik-ingenierie.com/blog/
On Tue, Jan 8, 2013 at 3:49 PM, Keith Young <yo...@gmail.com> wrote:
> >> Encourage JSR223 Samplers + Groovy + Caching instead of Beanshell
>
> Can someone point me to some documentation that outlines this better? If I
> include a JSR223 sampler there is no option for Groovy. The wiki link in
> this message thread says to include groovy-VERSION-all.jar in the
> jmeter/bin directory, but a download of Groovy 2.0.6 doesn't have that jar.
> Is the groovy-2.0.6.jar enough?
>
> What caching is the above point referring to?
>
> Sorry for these questions on the dev list, but that's where this thread
> is... :)
>
> Cheers,
> Keith.
>
>
> On 27 December 2012 05:06, Milamber <mi...@apache.org> wrote:
>
> >
> >
> > Le 24/12/2012 13:20, Philippe Mouawad a ecrit :
> >
> > Hello,
> >>
> >> I am kind of annoyed of reading articles, blogs that say JMeter cannot
> >> perform high Load Tests, consumes lot of memory, generates OutOfMemory
> ...
> >>
> >> This has become a kind of "Urban Legend" partly due:
> >> - to issues that have been fixed for a while now
> >> - and partly In my opinion to some default configuration parameters that
> >> lead to these issues
> >>
> >> In my opinion, we should:
> >>
> >> 1) change these defaults to avoid new comers, beginners fall into all
> >> these
> >> traps and others check they are using it well:
> >>
> >> - Save Service using XML output => Change to CSV
> >>
> >
> > Yes, CSV seems a better default type to the results file.
> >
> >
> > - Distributed Mode that uses the Standard which is far from being
> the
> >> best performing Sample Sender => Change to Batch or StrippedBatch
> >>
> >
> > Why Batch ou StrippedBatch ? Why not Asynch or Diskstore?
> >
> >
> >
> >> 2) Add warnings on GUIs of all elements that are more suited during
> >> Scripting than during Load Test :
> >>
> >> - View Result Tree (I keep seeing people use this element during
> High
> >> Load Test ! )
> >> - View Results in Table
> >> - Graph Results
> >> - ...
> >>
> >
> > JMeter can be used for functional tests. Warnings on GUI for the 'heavy'
> > elements can be unpleasant.
> >
> > Perhaps add a menu/button option "Check script for load test" which
> > display some warning (in a box or another way) when heavy elements are
> > found in the tree.
> > This option can be enabled by a property to checked before every load
> tests
> >
> >
> > 3) Add a popup warning when Start and Remote Start are clicked from GUI
> to
> >> encourage NON GUI mode use (we could add a checkbox Remind Me later
> which
> >> could be unchecked to avoid it again, but at least user would know about
> >> it).
> >>
> >
> > See comment in 2)
> >
> >
> >
> >
> > 4) Finally use some kind of visual indicator (RED background) on some
> >> options that have high impact on performance:
> >>
> >> - Javascript as scripting language
> >> - Body (unescaped) in Regular Expression Extractor (*this one is a
> >> real
> >> performance killer !*)
> >> - Encourage JSR223 Samplers + Groovy + Caching instead of Beanshell
> >> - ...
> >>
> >
> > point 2) too
> > The "check script for load test" wizard can displaying warnings for this
> > elements, and give some tips for performance
> >
> >
> >
> >> Maybe we should post this mail on user mailing list to see what users
> >> think
> >> about it.
> >>
> >>
> >
>
--
Cordialement.
Philippe Mouawad.