Hello Stephane et team,
We are currently using the HTTP protocol disableClientSharing setting in Gatling 2.3 for simulating large number of clients with dedicated SSL session cache.
Looks like this functionality is no longer available in Gatling 3.0 (by checking documentation and source code). Is there a different method for us to simulate this functionality when we migrate to Gatling 3.0?
Thank you much for great product and support all along.
I think there’s a misunderstanding here. Connections have their own SSL session.
The point of disableClientSharing was to let you pass different TrustManagers and KeyManagers per virtual users. Indeed, this feature was a niche and we haven’t ported it on Gatling 3 so far.
We did the following experiment to understand the SSL connections to our target server load balancer:
- We set up 5 virtual users, each of which sent 4 requests in 4 separate connections (REST API). First user sent all the requests, followed by the second, third and so on. In the tcpdump logs, we found one (1) unique SSL session ID being reused in SSL Client Hello messages in all connections (except the first) from 5 virtual users.
- We enabled “disableClientSharing”, repeated the experiment, and found five (5) unique SSL session ID being reused, one for each virtual user’s connections.
We need this functionality to ensure our target server load balancer can be properly configured to handle the expected volume of client SSL connections with SSL session resumption (as we’re aware of the high CPU cost of full SSL handshake vs. abbreviated SSL handshake). We hope it continues to be available in Gatling 3.0 and beyond.
You have a point.
We were playing with SSL Session invalidation, but that’s not right.
We’re going to have each virtual user have its own SSLContext instead of using a global one, unless shareConnections is enabled.