SSL handshake timeout

[Mihai Stanescu]

Hi all,

While running an SSL connection + authentication benchmark for Vertx net sockets, the presented error was observed on the client side (which is another machine from the vertx/server side)

The interesting fact is that the CPU load on the server machine is just 50% and not increasing so somehow not all resources are used.

Why is not 100% CPU usage? Assuming that SSL handshake is a CPU-bound operation ?

Some details:

Number of established connections when timeout happens: 80k

Rate of connections requests: 150 / sec

CPU usage: 50%

Cores: 16

Memory: 32 GB

vertx.eventbus.messages.pending-local = 170,000 (this is due to internal message exchange to authenticate the connection which requires some event bus messages however the interesting part is that it is so high)

Just disabling the SSL a rate of 200 connections/sec is stable and vertx.eventbus.messages.pending-local does not increase.

Regards

[Julien Viet]

On Oct 6, 2016, at 6:49 PM, Mihai Stanescu <mihai.s...@gmail.com> wrote:

Hi all,

While running an SSL connection + authentication benchmark for Vertx net sockets, the presented error was observed on the client side (which is another machine from the vertx/server side)

The interesting fact is that the CPU load on the server machine is just 50% and not increasing so somehow not all resources are used.

Why is not 100% CPU usage? Assuming that SSL handshake is a CPU-bound operation ?

norman maurer says so when he compares JDK SSL and OpenSSL:

https://speakerdeck.com/normanmaurer/netty-one-framework-to-rule-them-all?slide=30

can you give OpenSSL a spin ?

Some details:

Number of established connections when timeout happens: 80k

Rate of connections requests: 150 / sec

CPU usage: 50%

Cores: 16

Memory: 32 GB

vertx.eventbus.messages.pending-local = 170,000 (this is due to internal message exchange to authenticate the connection which requires some event bus messages however the interesting part is that it is so high)

Just disabling the SSL a rate of 200 connections/sec is stable and vertx.eventbus.messages.pending-local does not increase.

Regards

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/CALuWX9MMwjRFEsoX1f5VQcJM3Brz0Fy1FwYWiAu_b4b9bvWX7A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[yahim stnsc]

I have started looking into the code i did not find this explanation, but more info what i observed from putting some breakpoints.

Expensive SSL handshake computations are performed on vertx-evenloop threads which are shared with the eventloop verticles. I have mixed feelings about this. An SSL handshake takes 50 msec and can hinder performance of existing stuff. 

How can i throttle the amount of SSH handshakes being performed?  I could not see a way to apply  back-pressure.

I noticed the upgradeToSsl method in NetSocket however did not actually work when i issued the command:

openssl s_client -connect localhost:11000

Is this working only in STARTTLS mode?

[Julien Viet]

On Oct 7, 2016, at 3:37 PM, yahim stnsc <mihai.s...@gmail.com> wrote:

I have started looking into the code i did not find this explanation, but more info what i observed from putting some breakpoints.

Expensive SSL handshake computations are performed on vertx-evenloop threads which are shared with the eventloop verticles. I have mixed feelings about this. An SSL handshake takes 50 msec and can hinder performance of existing stuff. 

have you tried OpenSSL ?

How can i throttle the amount of SSH handshakes being performed?  I could not see a way to apply  back-pressure.

what kind of back pressure would you like here ? it’s not clear what you mean

I noticed the upgradeToSsl method in NetSocket however did not actually work when i issued the command:

openssl s_client -connect localhost:11000

Is this working only in STARTTLS mode?

I think yes.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/f820eb15-ce43-4184-8d90-b897b4db7706%40googlegroups.com.