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+ ??"<[email protected]>; ????????: 2019??2??15??(??????) ????10:03 ??????: "JMeter Users List"<[email protected]>; ????: ?????? Jmeter 4.0 and jmeter 5.0 comparison Thank you very much! ------------------ ???????? ------------------ ??????: "Philippe Mouawad"<[email protected]>; ????????: 2019??2??15??(??????) ????5:00 ??????: "JMeter Users List"<[email protected]>; ????: 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+ ?? <[email protected]> wrote: > hi ??excuse me > > > ------------------ ???????? ------------------ > ??????: "1+ ??"<[email protected]>; > ????????: 2019??2??13??(??????) ????10:35 > ??????: "user-subscribe"<[email protected]>; > > ????: 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.
