Hi Konstantin,
thank you for your quick and helpful reply. It's working now.
Indeed i tried to set the parameter:
httpclient.reset_state_on_thread_group_iteration to "false" but NOT together
with the httpclient4.time_to_live parameter.
>From my quick tests i see that if i set the parameter:
>httpclient4.time_to_live to "20000" then i see only one CONNECT and then 20 x
>HTTPs POST and then one Close.Setting the parameter: httpclient4.time_to_live
>to lets say 3000 (standard is 2000) then not all of the 20 HTTPs Calls make it
>inside one session.Thus i think the parameter: httpclient4.time_to_live is the
>key for my purpose.So i have to put the parameter to a higher value to make
>all my POST calls pass - but somehow im not sure if this is really something
>for the future.Imagine i will have 500 HTTPs calls in my test plan insted of
>only 20 - and i will takes 10min. to run them all - should i set this value to
>more then 10min?
Im not feel good about this. Or do i have to split the calls to multiple
threads?
Maybe you can help me to understand this - as im a user of jmeter since 2.11 :D
:) and in 2.11 the behaviour was quite different.In Jmeter 2.11 this behaviour
(keeping up the ssl session) was managed by the parameters:
https.sessioncontext.shared and https.use.cached.ssl.context which is
deprecated since 5.0.
BrMarkus
Am Dienstag, 20. August 2019, 13:20:44 MESZ hat Konstantin Kalinin
<[email protected]> Folgendes geschrieben:
Hi Markus,
Try tuning these JMeter properties:
httpclient.reset_state_on_thread_group_iteration
https://jmeter.apache.org/usermanual/properties_reference.html#ssl_config
httpclient4.time_to_live
https://jmeter.apache.org/usermanual/properties_reference.html#httpclient4
20.08.2019, 14:05, "Markus Obermann" <[email protected]>:
> Hello,
> im (still) using JMeter 5.0 and got a test plan with a keystore (with only
> one cert), a http request default (where i have defined my https server and
> port).In the system.properties ive enabled the ssl debug for: sslcontext,
> session.
> Now i have one thread (loop only once) with 20 HTTPs POST-calls to my
> webserver - and now here is my problem.
> I see a CONNECT and i see the whole ssl-handshake stuff running perfectly.I
> see the POST and the data which is sent to my server (only few bytes)I see a
> client close
> And this runs for all 20 calls.
>
> In my console i see:System property jdk.tls.client.cipherSuites is set to
> 'null'
> System property jdk.tls.client.cipherSuites is set to 'null'trigger seeding
> of SecureRandomdone seeding SecureRandom%% No cached client session%%
> Initialized: [Session-1, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384]%% Cached
> client session: [Session-1, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384]Test 1-1:
> setSoTimeout(0) calledTest 1-1: called close()Test 1-1: called
> closeInternal(true)Test 1-1: SEND TLSv1.2 ALERT: warning, description =
> close_notifyTest 1-1: called closeSocket(true)%% Cached client session:
> [Session-1, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384]%% Try resuming:
> [Session-1, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384] from Port 43434%%
> Invalidated: [Session-1, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384]
> And now JMeter start a new Session (Session-2) with all stuff and this for
> all 20 calls.
> Do anyone can help me how i can force JMeter to reuse the SSL-Session?I want
> to have one Session - then 20 calls - then a close.
> It seems that it's JMeter who force the close it's NOT my Webserver. I've
> tried with curl and it worked perfectly.
> Btw.I'm using java jre 9.0.4+11 on a linux client.
>
> thanks in advice for your help.
--
Konstantin Kalinin
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
