jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: jmeter.properties cleanup
Date Thu, 09 May 2013 09:45:06 GMT
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.

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