转发:Jmeter 4.0 and jmeter 5.0 comparison

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

转发:Jmeter 4.0 and jmeter 5.0 comparison

1+ ∞
hi ,excuse me


------------------ 原始邮件 ------------------
发件人: "1+ ∞"<[hidden email]>;
发送时间: 2019年2月13日(星期三) 上午10:35
收件人: "user-subscribe"<[hidden email]>;

主题: Jmeter 4.0 and jmeter 5.0 comparison



The same concurrency, jmeter4.0 and jmeter 5.0 running results in the tps and response time gap is very large, Jmeter 5.0 tps is more than 700, in the jmeter4.0 above tps reached more than 2,000。


 At the same time, when jmeter 5.0 is used, a large number of tcp states appear as time_wait connections.


Note: The configuration of jmeter 5.0 and jmeter 4.0 is not only distributed, but the rest of the configuration is the default configuration after the official download.
pmd
Reply | Threaded
Open this post in threaded view
|

Re: Jmeter 4.0 and jmeter 5.0 comparison

pmd
Hello,
There is a documented major change in JMeter 5.0 :

   - https://jmeter.apache.org/changes.html#Incompatible%20changes

*Since JMeter 5.0, when using default HC4 Implementation, JMeter will reset
HTTP state (SSL State + Connections) on each thread group iteration. If you
don't want this behaviour, set
httpclient.reset_state_on_thread_group_iteration=false*

We do this, because a new Thread Group iteration is a new user in general,
so the SSL Handshake would occur again.
If a new Thread Group iteration is not a new user for you , set
httpclient.reset_state_on_thread_group_iteration=false

So first thing to do would be comparing same application version  with
JMeter 4.0 and JMeter 5.0 with
httpclient.reset_state_on_thread_group_iteration=false.

If performances are similar, then either a new Thread Group iteration is a
new user and you need to set
httpclient.reset_state_on_thread_group_iteration=true
and then:

   - Either your JMeter instance is overloaded, then increase its CPU
   - Either it' s your application which is not able to handle the SSL
   Handshake efficiently enough


Regards

On Wed, Feb 13, 2019 at 3:44 AM 1+ ∞ <[hidden email]> wrote:

> hi ,excuse me
>
>
> ------------------ 原始邮件 ------------------
> 发件人: "1+ ∞"<[hidden email]>;
> 发送时间: 2019年2月13日(星期三) 上午10:35
> 收件人: "user-subscribe"<[hidden email]>;
>
> 主题: Jmeter 4.0 and jmeter 5.0 comparison
>
>
>
> The same concurrency, jmeter4.0 and jmeter 5.0 running results in the tps
> and response time gap is very large, Jmeter 5.0 tps is more than 700, in
> the jmeter4.0 above tps reached more than 2,000。
>
>
>  At the same time, when jmeter 5.0 is used, a large number of tcp states
> appear as time_wait connections.
>
>
> Note: The configuration of jmeter 5.0 and jmeter 4.0 is not only
> distributed, but the rest of the configuration is the default configuration
> after the official download.



--
Cordialement.
Philippe Mouawad.
Reply | Threaded
Open this post in threaded view
|

回复: Jmeter 4.0 and jmeter 5.0 comparison

1+ ∞
Thank you very much!


------------------ 原始邮件 ------------------
发件人: "Philippe Mouawad"<[hidden email]>;
发送时间: 2019年2月15日(星期五) 凌晨5:00
收件人: "JMeter Users List"<[hidden email]>;

主题: Re: Jmeter 4.0 and jmeter 5.0 comparison



Hello,
There is a documented major change in JMeter 5.0 :

   - https://jmeter.apache.org/changes.html#Incompatible%20changes

*Since JMeter 5.0, when using default HC4 Implementation, JMeter will reset
HTTP state (SSL State + Connections) on each thread group iteration. If you
don't want this behaviour, set
httpclient.reset_state_on_thread_group_iteration=false*

We do this, because a new Thread Group iteration is a new user in general,
so the SSL Handshake would occur again.
If a new Thread Group iteration is not a new user for you , set
httpclient.reset_state_on_thread_group_iteration=false

So first thing to do would be comparing same application version  with
JMeter 4.0 and JMeter 5.0 with
httpclient.reset_state_on_thread_group_iteration=false.

If performances are similar, then either a new Thread Group iteration is a
new user and you need to set
httpclient.reset_state_on_thread_group_iteration=true
and then:

   - Either your JMeter instance is overloaded, then increase its CPU
   - Either it' s your application which is not able to handle the SSL
   Handshake efficiently enough


Regards

On Wed, Feb 13, 2019 at 3:44 AM 1+ ∞ <[hidden email]> wrote:

> hi ,excuse me
>
>
> ------------------ 原始邮件 ------------------
> 发件人: "1+ ∞"<[hidden email]>;
> 发送时间: 2019年2月13日(星期三) 上午10:35
> 收件人: "user-subscribe"<[hidden email]>;
>
> 主题: Jmeter 4.0 and jmeter 5.0 comparison
>
>
>
> The same concurrency, jmeter4.0 and jmeter 5.0 running results in the tps
> and response time gap is very large, Jmeter 5.0 tps is more than 700, in
> the jmeter4.0 above tps reached more than 2,000。
>
>
>  At the same time, when jmeter 5.0 is used, a large number of tcp states
> appear as time_wait connections.
>
>
> Note: The configuration of jmeter 5.0 and jmeter 4.0 is not only
> distributed, but the rest of the configuration is the default configuration
> after the official download.



--
Cordialement.
Philippe Mouawad.
Reply | Threaded
Open this post in threaded view
|

回复: Jmeter 4.0 and jmeter 5.0 comparison

1+ ∞
In the case where jmeter 5.0 is httpclient.reset_state_on_thread_group_iteration=true, why is the close_wait state in the tcp connection a lot?


httpclient.reset_state_on_thread_group_iteration=true

httpclient.reset_state_on_thread_group_iteration=false


------------------ 原始邮件 ------------------
发件人: "1+ ∞"<[hidden email]>;
发送时间: 2019年2月15日(星期五) 上午10:03
收件人: "JMeter Users List"<[hidden email]>;
主题: 回复: Jmeter 4.0 and jmeter 5.0 comparison

Thank you very much!


------------------ 原始邮件 ------------------
发件人: "Philippe Mouawad"<[hidden email]>;
发送时间: 2019年2月15日(星期五) 凌晨5:00
收件人: "JMeter Users List"<[hidden email]>;

主题: Re: Jmeter 4.0 and jmeter 5.0 comparison



Hello,
There is a documented major change in JMeter 5.0 :

   - https://jmeter.apache.org/changes.html#Incompatible%20changes

*Since JMeter 5.0, when using default HC4 Implementation, JMeter will reset
HTTP state (SSL State + Connections) on each thread group iteration. If you
don't want this behaviour, set
httpclient.reset_state_on_thread_group_iteration=false*

We do this, because a new Thread Group iteration is a new user in general,
so the SSL Handshake would occur again.
If a new Thread Group iteration is not a new user for you , set
httpclient.reset_state_on_thread_group_iteration=false

So first thing to do would be comparing same application version  with
JMeter 4.0 and JMeter 5.0 with
httpclient.reset_state_on_thread_group_iteration=false.

If performances are similar, then either a new Thread Group iteration is a
new user and you need to set
httpclient.reset_state_on_thread_group_iteration=true
and then:

   - Either your JMeter instance is overloaded, then increase its CPU
   - Either it' s your application which is not able to handle the SSL
   Handshake efficiently enough


Regards

On Wed, Feb 13, 2019 at 3:44 AM 1+ ∞ <[hidden email]> wrote:

> hi ,excuse me
>
>
> ------------------ 原始邮件 ------------------
> 发件人: "1+ ∞"<[hidden email]>;
> 发送时间: 2019年2月13日(星期三) 上午10:35
> 收件人: "user-subscribe"<[hidden email]>;
>
> 主题: Jmeter 4.0 and jmeter 5.0 comparison
>
>
>
> The same concurrency, jmeter4.0 and jmeter 5.0 running results in the tps
> and response time gap is very large, Jmeter 5.0 tps is more than 700, in
> the jmeter4.0 above tps reached more than 2,000。
>
>
>  At the same time, when jmeter 5.0 is used, a large number of tcp states
> appear as time_wait connections.
>
>
> Note: The configuration of jmeter 5.0 and jmeter 4.0 is not only
> distributed, but the rest of the configuration is the default configuration
> after the official download.



--
Cordialement.
Philippe Mouawad.
Reply | Threaded
Open this post in threaded view
|

Re: 回复: Jmeter 4.0 and jmeter 5.0 comparison

Felix Schumacher

Am 15.02.19 um 07:46 schrieb 1+ ∞:
> In the case where jmeter 5.0 is
> httpclient.reset_state_on_thread_group_iteration=true, why is the
> close_wait state in the tcp connection a lot?


If my google foo didn't let me down, this indicates that the client
didn't close the connection yet. Can you post a minimal test plan that
reproduces that issue, that we could use?

Some ideas to investigate on your side. Do you use keepalive on your
requests? Is the behavior different, when you disable keepalive?

>
>
> httpclient.reset_state_on_thread_group_iteration=true

The mailing list strips most images from the mails (as it has done in
this case), so we can't see, what you want to show us.

Regards,

  Felix

>
> httpclient.reset_state_on_thread_group_iteration=false
>
>
> ------------------ 原始邮件 ------------------
> *发件人:* "1+ ∞"<[hidden email]>;
> *发送时间:* 2019年2月15日(星期五) 上午10:03
> *收件人:* "JMeter Users List"<[hidden email]>;
> *主题:* 回复: Jmeter 4.0 and jmeter 5.0 comparison
>
> Thank you very much!
>
>
> ------------------ 原始邮件 ------------------
> 发件人: "Philippe Mouawad"<[hidden email]>;
> 发送时间: 2019年2月15日(星期五) 凌晨5:00
> 收件人: "JMeter Users List"<[hidden email]>;
>
> 主题: Re: Jmeter 4.0 and jmeter 5.0 comparison
>
>
>
> Hello,
> There is a documented major change in JMeter 5.0 :
>
>    - https://jmeter.apache.org/changes.html#Incompatible%20changes
>
> *Since JMeter 5.0, when using default HC4 Implementation, JMeter will
> reset
> HTTP state (SSL State + Connections) on each thread group iteration.
> If you
> don't want this behaviour, set
> httpclient.reset_state_on_thread_group_iteration=false*
>
> We do this, because a new Thread Group iteration is a new user in general,
> so the SSL Handshake would occur again.
> If a new Thread Group iteration is not a new user for you , set
> httpclient.reset_state_on_thread_group_iteration=false
>
> So first thing to do would be comparing same application version  with
> JMeter 4.0 and JMeter 5.0 with
> httpclient.reset_state_on_thread_group_iteration=false.
>
> If performances are similar, then either a new Thread Group iteration is a
> new user and you need to set
> httpclient.reset_state_on_thread_group_iteration=true
> and then:
>
>    - Either your JMeter instance is overloaded, then increase its CPU
>    - Either it' s your application which is not able to handle the SSL
>    Handshake efficiently enough
>
>
> Regards
>
> On Wed, Feb 13, 2019 at 3:44 AM 1+ ∞ <[hidden email]>
> wrote:
>
> > hi ,excuse me
> >
> >
> > ------------------ 原始邮件 ------------------
> > 发件人: "1+ ∞"<[hidden email]>;
> > 发送时间: 2019年2月13日(星期三) 上午10:35
> > 收件人: "user-subscribe"<[hidden email]>;
> >
> > 主题: Jmeter 4.0 and jmeter 5.0 comparison
> >
> >
> >
> > The same concurrency, jmeter4.0 and jmeter 5.0 running results in
> the tps
> > and response time gap is very large, Jmeter 5.0 tps is more than 700, in
> > the jmeter4.0 above tps reached more than 2,000。
> >
> >
> >  At the same time, when jmeter 5.0 is used, a large number of tcp states
> > appear as time_wait connections.
> >
> >
> > Note: The configuration of jmeter 5.0 and jmeter 4.0 is not only
> > distributed, but the rest of the configuration is the default
> configuration
> > after the official download.
>
>
>
> --
> Cordialement.
> Philippe Mouawad.