You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Philippe Mouawad <p....@ubik-ingenierie.com> on 2018/05/07 19:59:23 UTC
HTTP Request: Modify Timeout Default Values
Hello,
Don't you think we should change HTTP default connect and read timeout ?
They are currently infinite and frequently I see users on Stackoverflow or
in real life think that JMeter has hanged just because it is waiting for
the response from a hanged server.
Shouldn't we make the defaults a bit better:
- 3 sec for connect timeout
- 30 sec for read timeout
Regards
Philippe M.
Re: HTTP Request: Modify Timeout Default Values
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 07.05.2018 um 21:59 schrieb Philippe Mouawad:
> Hello,
> Don't you think we should change HTTP default connect and read timeout ?
>
> They are currently infinite and frequently I see users on Stackoverflow or
> in real life think that JMeter has hanged just because it is waiting for
> the response from a hanged server.
>
> Shouldn't we make the defaults a bit better:
>
> - 3 sec for connect timeout
> - 30 sec for read timeout
+1 for setting some timeout as default, do these timeouts mirror the
timeouts of current browsers?
I think that it should be possible to revert to the old behaviour by a
global switch - at least for a few versions.
Regards,
Felix
>
> Regards
>
> Philippe M.
>
Re: HTTP Request: Modify Timeout Default Values
Posted by Vladimir Sitnikov <si...@gmail.com>.
>What do you suggest ?
I'm inclined to "automatic hard stop at <<test duration + some slack time
value>>".
For instance, if a threadgroup has been configured to last for 10 seconds,
then JMeter should somehow hard stop at 15 seconds (or even at 10).
The results should include "max time 10 seconds (or whatever)", and the
status of interrupted sample should be "error".
On a plus side: we can use "the remaining test duration" as a "downstream
timeout" so the timeout gets propagated and we have more changes the whole
thing will get stopped properly.
>if you have a patch showing how yoy would do it, it would be great
I'm not sure if this is the most important UI problem.
I do remember though that certain JMeter versions failed to end test in
presence of long timers. It did bother me.
>Maybe, but I feel those are reasonable timeouts nowadays
Just my 2 cents: I do not find setting default timeouts to 30 (or whatever
values) solves real problems.
On the other hand, making JMeter to honour the configured test schedule
would definitely help a lot.
Vladimir
Re: HTTP Request: Modify Timeout Default Values
Posted by Philippe Mouawad <ph...@gmail.com>.
On Tuesday, May 8, 2018, Vladimir Sitnikov <si...@gmail.com>
wrote:
> 1) The timeout property is there so the ones who do do understand can tweak
> it
>
> 2) In case you mean "JMeter fails to stop/terminate in presence of long
> requests" (e.g.
> https://stackoverflow.com/questions/16286500/jmeter-
> http-request-hangs-probably-on-overloaded-network
> ),
> then it should be addressed separately.
>
> I believe, JMeter should stop all the thread groups/samplers as per
> scheduler configuration.
> Does it terminate http requests in question?
on regular shutdown , it will wait for requests to end or to timeout.
Only on stop (interrupt for interruptable samplers) , it interrupts pending
requests , so by default it will not end.
What do you suggest ?
> If it does what is the issue then?
>
> >You mean something like:
> > - Threads on pending request
> > - Thread waiting
>
> Exactly. Current JMeter UI (and console mode as well) gives no clue on what
> the threads are doing. Are they hitting the server? Are they waiting?
> How many of them are stuck on a single request for 5+seconds?
> I'm not sure which states to show, however that could greatly simplify
> analysis of "incorrect timer placement, etc, etc".
>
> Note: timeout of 30 seconds is way too big to be user-friendly in terms of
> "immediate feedback on wrong configuration".
> As I start a test, I would like to get some feedback within 5 seconds. Has
> it been started? Is it stuck?
if you have a patch showing how yoy would do it, it would be great
>
> >I didn't find answers regarding default values.
>
> The idea there is "the defaults are very high". Newbies could be screwed if
> JMeter behaves very different from a regular browser (e.g. 30 second
> timeout instead of 1500).
Maybe, but I feel those are reasonable timeouts nowadays.
>
> Vladimir
>
--
Cordialement.
Philippe Mouawad.
Re: HTTP Request: Modify Timeout Default Values
Posted by Vladimir Sitnikov <si...@gmail.com>.
1) The timeout property is there so the ones who do do understand can tweak
it
2) In case you mean "JMeter fails to stop/terminate in presence of long
requests" (e.g.
https://stackoverflow.com/questions/16286500/jmeter-http-request-hangs-probably-on-overloaded-network
),
then it should be addressed separately.
I believe, JMeter should stop all the thread groups/samplers as per
scheduler configuration.
Does it terminate http requests in question?
If it does what is the issue then?
>You mean something like:
> - Threads on pending request
> - Thread waiting
Exactly. Current JMeter UI (and console mode as well) gives no clue on what
the threads are doing. Are they hitting the server? Are they waiting?
How many of them are stuck on a single request for 5+seconds?
I'm not sure which states to show, however that could greatly simplify
analysis of "incorrect timer placement, etc, etc".
Note: timeout of 30 seconds is way too big to be user-friendly in terms of
"immediate feedback on wrong configuration".
As I start a test, I would like to get some feedback within 5 seconds. Has
it been started? Is it stuck?
>I didn't find answers regarding default values.
The idea there is "the defaults are very high". Newbies could be screwed if
JMeter behaves very different from a regular browser (e.g. 30 second
timeout instead of 1500).
Vladimir
Re: HTTP Request: Modify Timeout Default Values
Posted by Philippe Mouawad <ph...@gmail.com>.
On Mon, May 7, 2018 at 10:15 PM, Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:
> >They are currently infinite and frequently I see users on Stackoverflow
>
> Could you provide examples?
>
https://stackoverflow.com/search?q=%5Bjmeter%5D%C2%A0hangs
Not all of them but many.
I remember having answered at least 10 times to such questions on SO.
And in real life, 11 days ago I had that remarks and the issue was missing
timeout. And again it is very frequent.
>
> > or in real life think that JMeter has hanged
>
> Does that mean "I've started the load and nothing happens"?
>
More frequently, JMeter test does not end.
> Could we draw a spinner that does somehow clarify if JMeter is fine?
>
Can you clarify ?
> Currently we have "number of active threads", however it does not
> distinguish between a thread hitting the server and a thread blocked on a
> timer.
You mean something like:
- Threads on pending request
- Thread waiting
>
> I'm not sure if adding a UI for user-facing thread dump is a good thing,
> but I'm always ending up with capturing thread dumps.
>
We have such thing. But for example the case happened in non gui mode.
>
> > - 3 sec for connect timeout
> > - 30 sec for read timeout
>
> The listed values might be too low for those who test 10+ second response
> times.
>
Yes I agree.
>
> There's a note that Chrome/Firefox were happy to wait for 1500 seconds:
> https://stackoverflow.com/questions/1342310/where-can-i-
> find-the-default-timeout-settings-for-all-browsers?utm_
> medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa#
> comment65281083_1343963
I didn't find answers regarding default values.
FF about:config shows very high values but I read they were not always
used.
>
>
> Vladimir
>
--
Cordialement.
Philippe Mouawad.
Re: HTTP Request: Modify Timeout Default Values
Posted by Vladimir Sitnikov <si...@gmail.com>.
>They are currently infinite and frequently I see users on Stackoverflow
Could you provide examples?
> or in real life think that JMeter has hanged
Does that mean "I've started the load and nothing happens"?
Could we draw a spinner that does somehow clarify if JMeter is fine?
Currently we have "number of active threads", however it does not
distinguish between a thread hitting the server and a thread blocked on a
timer.
I'm not sure if adding a UI for user-facing thread dump is a good thing,
but I'm always ending up with capturing thread dumps.
> - 3 sec for connect timeout
> - 30 sec for read timeout
The listed values might be too low for those who test 10+ second response
times.
There's a note that Chrome/Firefox were happy to wait for 1500 seconds:
https://stackoverflow.com/questions/1342310/where-can-i-find-the-default-timeout-settings-for-all-browsers?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa#comment65281083_1343963
Vladimir