jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Milamber <milam...@apache.org>
Subject Re: PERFORMANCE => Changing JMeter defaults to ensure better performances by default
Date Thu, 27 Dec 2012 10:06:50 GMT


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.
>


Mime
View raw message