I searched the archive and found this relevant article:
Ref https://groups.google.com/forum/#!topic/gatling/-8gckFP3Yt0
I have been asked to accurately simulate the TLS/SSL termination load on the server, as would happen with real clients.
That is, use gatling to ensure the TLS/SSL connections (including reuse) are the same as the client we have.
Each client has three processes, each of which open a single SSL connection and then reuse it when making the next REST call. For 1000 clients, there will be 3000 SSL connections.
Process A → REST call A.1
Process B → REST call B.1
Process C → REST call C.1, C.2, C.3 (sharing the SSL connection of process C)
I am thinking of having individual single-scenario simulation for A, B and using httpProtocol.disableClientSharing. This will ensure that there will be one SSL connection per user.
However, C is a multi-scenario simulation.
setUp (
processC.scnHeartbeat.inject(ramp(scnAgents users) over (scnAgents seconds)),
processC.scnLogs.inject(ramp(scnAgents users) over (scnAgents seconds)),
processC.scnStats.inject(ramp(scnAgents users) over (scnAgents seconds))
).protocols(…)
I want to ensure that there will be exactly “scnAgents” number of SSL connections from processC simulation.
I think that is what will happen with the default ahc settings and NOT using disableClientSharing. But, a confirmation would be helpful.
Thank you.
I have been asked to accurately simulate the TLS/SSL termination load on
the server, as would happen with real clients.
You mean YOUR real clients, right? Not browsers.
That is, use gatling to ensure the TLS/SSL connections (including reuse)
are the same as the client we have.
Each client has three processes, each of which open a single SSL
connection and then reuse it when making the next REST call. For 1000
clients, there will be 3000 SSL connections.
Process A -> REST call A.1
Process B -> REST call B.1
Process C -> REST call C.1, C.2, C.3 (sharing the SSL connection of
process C)
I am thinking of having individual single-scenario simulation for A, B and
using httpProtocol.disableClientSharing. This will ensure that there will
be one SSL connection per user.
No, disableClientSharing has nothing to do with this. disableClientSharing
is for having one single AsyncHttpClient instance per virtual user, so you
can configure them differently. Main usage is to pass different keystores
per user.
By default, connections are not shared amongst virtual users.
However, C is a multi-scenario simulation.
setUp (
processC.scnHeartbeat.inject(ramp(scnAgents users) over (scnAgents
seconds)),
processC.scnLogs.inject(ramp(scnAgents users) over (scnAgents
seconds)),
processC.scnStats.inject(ramp(scnAgents users) over (scnAgents
seconds))
).protocols(....)
I want to ensure that there will be exactly "scnAgents" number of SSL
connections from processC simulation.
IMHO, what you want is actually something like:
val scn = randomSwitch {
processC.scnHeartbeat,
processC.scnLogs.
processC.scnStats
}
Thank you. Yes, I was referring to my real clients which use the REST API, not browsers or browser-based apps.
If connections are not shared among virtual users, what will happen if I set ahc configuration “allowSslConnectionPool” to false (default value is true)?
Appreciate the tip about “randomSwitch”.
If connections are not shared among virtual users, what will happen if I
set ahc configuration "allowSslConnectionPool" to false (default value is
true)?
Disable keepalive, connections will be closed after each request.
May I suggest a more accurate name for the property – “allowSslConnectionReuse” ? Minor/low-priority.
How do I sign up to be a gatling OSS developer? I’d like to contribute.
Nothing to sign-up. Just send a pull-request on Github.
Cheers
Nicolas
I disagree on changing the name.
Those properties map one to one the ones in AsyncHttpClient and I think it’s a good thing.
If we find names that make more sense, we have to change them in AHC first, which mean targeting AHC2 and Netty 4.