Double lower rps when running against https

Hi guys,

I’m using Gatling 2.3.1 for my tests. I have successfully ran 10000 RPS against http server with simple Get 200 endpoint (without any logic inside). But when I enable https on the same server and run the same scenario against https, I get max 5000 RPS. If i try to get more RPS, I receive next exception:

12:08:24.595 [DEBUG] i.g.h.a.AsyncHandler - Request ‘Warmup’ failed for user 53976 handshake timed out
at io.netty.handler.ssl.SslHandler.handshake(…)(Unknown Source)
Wrapped by: handshake timed out
at org.asynchttpclient.netty.SimpleFutureListener.operationComplete(
at io.netty.util.concurrent.DefaultPromise.notifyListener0(
at io.netty.util.concurrent.DefaultPromise.notifyListeners0(
at io.netty.util.concurrent.DefaultPromise.notifyListenersNow(
at io.netty.util.concurrent.DefaultPromise.notifyListeners(
at io.netty.util.concurrent.DefaultPromise.tryFailure(
at io.netty.handler.ssl.SslHandler.notifyHandshakeFailure(
at io.netty.handler.ssl.SslHandler.access$1100(
at io.netty.handler.ssl.SslHandler$
at io.netty.util.concurrent.PromiseTask$
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(
at io.netty.util.concurrent.SingleThreadEventExecutor$

Could you please tell if such a decrease in performance when enabling https is ok?
And what can I do with this exception?


Also I try to run gatling from two instances in parallel and I manage to get 6000 RPS from two gatling machines against https server.
But when I try to run 7000 RPS (3500 RPS per gatling instance), one of two machines start to consume much more RAM (from 300M when running on one instance to 4G) then usual and response time increases.

5000 rps from one box and 6000 rps from 2 boxes? You’re most likely saturating your infrastructure under load (app, network, etc).

Hi Stephane,

Thanks for reply.
Looks like I’ve found an issue.

Running on 1 instance (4 cores, 8G) 4000 RPS, I can see that opened connections during the test increase very fast from 55 to 28000 and fails with handshake timed out exception.

On bigger instance (8 cores, 16G) 8000 RPS, runs without exceptions and during same test has max 1300 opened connections.