jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Milamber <milam...@apache.org>
Subject Re: jmeter.properties cleanup
Date Thu, 09 May 2013 10:38:19 GMT

Le 09/05/2013 11:31, sebb a ecrit :
> On 9 May 2013 11:15, Milamber <milamber@apache.org> wrote:
>> Le 09/05/2013 10:45, sebb a ecrit :
>>
>>> I don't see any need to tidy up the properties.
>>>
>>> As to the autoflush, I agree that the default should be false, as that
>>> improves performance.
>>
>> I suppose you would says: the default should be true (activating the
>> autoflush)?
>>
> No, I think the default should be false, as that improves performance
> for the normal case, and it is the original behaviour.

In my mind, the original behavior (current in 2.9) is autoflush to true 
(don't lost data).



>
>>> Let's see if a shutdown hook works.
>>>
>>> On 9 May 2013 10:10, Milamber <milamber@apache.org> wrote:
>>>> Le 09/05/2013 09:32, Philippe Mouawad a ecrit :
>>>>
>>>>> On Thursday, May 9, 2013, Milamber wrote:
>>>>>
>>>>>> Le 09/05/2013 08:16, Philippe Mouawad a ecrit :
>>>>>>
>>>>>>> On Thursday, May 9, 2013, Milamber wrote:
>>>>>>>
>>>>>>>     Le 08/05/2013 23:03, Philippe Mouawad a ecrit :
>>>>>>>>     Bad post, should have gone here
>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>> From: *Philippe Mouawad*
>>>>>>>>> Date: Wednesday, May 8, 2013
>>>>>>>>> Subject: jmeter.properties cleanup
>>>>>>>>> To: JMeter Users List <user@jmeter.apache.org>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> jmeter.properties has grown with a lot of properties
that maybe are
>>>>>>>>> not
>>>>>>>>> that useful.
>>>>>>>>> I find it a good thing that lot of things are configurable
in JMeter
>>>>>>>>> but
>>>>>>>>> maybe it's too much and one of the issues is users may
not find the
>>>>>>>>> really
>>>>>>>>> useful ones (recently for example with https.socket.protocols).
>>>>>>>>>
>>>>>>>>> I propose to remove the following:
>>>>>>>>>
>>>>>>>>>         - jmeter.loggerpanel.display=****false =>
It's so easy to
>>>>>>>>> just
>>>>>>>>> click it
>>>>>>>>>         - jmeter.errorscounter.display=****true =>
Why would someone
>>>>>>>>> not
>>>>>>>>> want
>>>>>>>>> this
>>>>>>>>>         feature ?
>>>>>>>>>         - jmeter.toolbar.display=true => Why would
someone not want
>>>>>>>>> this
>>>>>>>>> cool
>>>>>>>>>         feature ?
>>>>>>>>>         - jmeter.toolbar => Will users really want
to reorganize
>>>>>>>>> these
>>>>>>>>> icons ?
>>>>>>>>>         - jmeter.toolbar.icons => Same as before
>>>>>>>>>
>>>>>>>>>     If you are a JMeter plugins developer, you may want
to
>>>>>>>>> re-organize
>>>>>>>>> or
>>>>>>>> change the toolbar.
>>>>>>>>
>>>>>>>>          - onload.expandtree => Current default behaviour
seems fine
>>>>>>>> no ?
>>>>>>>>
>>>>>>>>>         - jmeter.save.saveservice.****autoflush =>
After some further
>>>>>>>>> thinking, why
>>>>>>>>>         would users not need this one ? If JMeter crashes
and some
>>>>>>>>> data
>>>>>>>>> is
>>>>>>>>> lost ,
>>>>>>>>>         then there are big chances that the test was
not that fine
>>>>>>>>> before
>>>>>>>>> the
>>>>>>>>> crash.
>>>>>>>>>
>>>>>>>>>     No! I prefer (and I put) this property to the value
"true" ! If
>>>>>>>>> you
>>>>>>>> make a
>>>>>>>> simple load test and we stop the test with a Ctrl-C, we lost
a lot of
>>>>>>>> results (with some tests in my case, I've lost the *entire*
results
>>>>>>>> (small
>>>>>>>> test of 5-10 min). Please don't touch this property, and
I recommend
>>>>>>>> to
>>>>>>>> put
>>>>>>>> to true by default. It's a very annoying behavior.
>>>>>>>>
>>>>>>>>
>>>>>>>> We could introduce a  shutdown hook to handle these Ctrl+C
cases.
>>>>>>>>
>>>>>>> In my opinion it should be false as performances for high throughput
>>>>>>> tests
>>>>>>> are way better. And imho default settings should  be the most
>>>>>>> performing
>>>>>>> for a load testing tool  no ?
>>>>>>>
>>>>>> Not sure. A new JMeter user can be disoriented if he don't see his
>>>>>> results.
>>>>>> I've prefer a reliable software that a more performance software
which
>>>>>> can
>>>>>> loose my results.
>>>>> With shutdown hook you won't loose results as quit signal will be
>>>>> trapped
>>>>> and we can flush the file, no ?
>>>>>
>>>>>> Perhaps, make this autoflush behavior more visible in JMeter UI.
For
>>>>>> example, add a checkbox in Test Plan (or a checkbox-menu) to
>>>>>> enable/disable
>>>>>> this option. (and add a warning message when the option is enabled
:
>>>>>> "you
>>>>>> can lost some results if you stop the test with Ctrl-C")
>>>>>>
>>>>>>
>>>>>> Do you think it s still needed with what  I described above ?
>>>>> What was the scenario that made you lost some resuts ?
>>>>
>>>>
>>>> A simple scenario :
>>>>
>>>> Thread group with 1 / 1 / infinite loop
>>>>        |-- Java Sampler with 1000 ms delay
>>>>
>>>>
>>>> Launch JMeter in non-gui mode, with 30 sec and Ctrl-C :
>>>>
>>>> milamber@ender:~/opt/apache-jmeter-2.10-SNAPSHOT/bin$ ./jmeter -n -t
>>>> ./lost-results.jmx -l myresults.csv
>>>> Creating summariser <summary>
>>>> Created the tree successfully using ./lost-results.jmx
>>>> Starting the test @ Thu May 09 10:05:23 WEST 2013 (1368090323095)
>>>> Waiting for possible shutdown message on port 4445
>>>> summary +      7 in     8s =    0.9/s Avg:  1076 Min:  1005 Max: 1162
>>>> Err:
>>>> 0 (0.00%) Active: 1 Started: 1 Finished: 0
>>>> summary +     27 in  30.2s =    0.9/s Avg:  1117 Min:  1023 Max: 1251
>>>> Err:
>>>> 0 (0.00%) Active: 1 Started: 1 Finished: 0
>>>> summary =     34 in    38s =    0.9/s Avg:  1108 Min:  1005 Max: 1251
>>>> Err:
>>>> 0 (0.00%)
>>>> ^C
>>>> milamber@ender:~/opt/apache-jmeter-2.10-SNAPSHOT/bin$ wc -l myresults.csv
>>>> 0 myresults.csv
>>>> milamber@ender:~/opt/apache-jmeter-2.10-SNAPSHOT/bin$ cat myresults.csv
>>>> <===
>>>> empty file
>>>> milamber@ender:~/opt/apache-jmeter-2.10-SNAPSHOT/bin$
>>>>
>>>> Not good in my opinion.
>>>>
>>>> Milamber
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>> Ok for the rest let's keep the statu quo if you think all are
needed.
>>>>>>>
>>>>>>>     I have doubts about those ones:
>>>>>>>>> # Netscape HTTP Cookie file
>>>>>>>>> cookies=cookies => What does it do ?
>>>>>>>>>
>>>>>>>>> We could try to remove them and if users want them, we
would have
>>>>>>>>> some
>>>>>>>>> bugzilla request to get them back.
>>>>>>>>>
>>>>>>>>>     If you remove these properties, you introduce a lot
of
>>>>>>>>> incompatibilty
>>>>>>>> changes and (in my opinion) you remove some freedom of the
user's
>>>>>>>> preferences. Please double check before remove.
>>>>>>>>
>>>>>>>> Milamber.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>


Mime
View raw message