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 <[email protected]>


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.






Reply via email to