Hi Support,
We are in the process of upgrading from v2 to v3.9 Gatling.
The changes are quite simple as it only includes the below list along with some renaming of func.
But when we test v3.9, we get alot of ConnectTimeoutException and io.netty.handler.ssl.StacklessSSLHandshakeException: Connection closed while SSL/TLS handshake was in progress.
My question is, are there things we need to also change specifically to network related configuration as we don’t get this errors in the v2 version of Gatling before.
Also we noticed when we do ps -ef|grep java, we see 2 instance running on Gatling 3.9 as opposed to v2 having only one.
- records.toList to simply readRecords
- Java 8 to 17
Gatling 2 used to shared a global SSLContext, resulting in SSLSession reuse between virtual users. This behavior is wrong when you’re not using shareConnections
.
Gatling 3 fixed this, resulting in more expensive but correct behavior.
Also we noticed when we do ps -ef|grep java, we see 2 instance running on Gatling 3.9 as opposed to v2 having only one.
Sorry, no idea how you could experience this. Please provide a reproducer.
thanks for your immediate reply.
I tested it now by adding maxConnectionsPerHost and it improves.
Is there a proper way to determine what value can be set for maxConnectionsPerHost ?
Is it as simple as virtual user = maxConnectionsPerHost ?
Thanks.
maxConnectionsPerHost
is only effective when fetching concurrent resources over HTTP/1.1.
I recommend against tweaking as the default value makes sense for most browsers.
Thanks @slandelle. I have another question, what is the proper approach to using shareConnections?
Would that be like in the Simulation:
def httpConf: HttpProtocolBuilder = http
.shareConnections
or can i set it via call to gatling.sh?
We’re not using the gatling.conf btw.