Nginx ssl handshake vs apache

Hi
I was watching this video by fastly ceo
http://youtu.be/zrSvoQz1GOs?t=24m44s
he talks about the nginx ssl handshake versus apache and comes to the
conclusion that apache was more efficient at mass handshakes due to
nginx blocking while it calls back to openssl

I was hoping to get other people’s opinion on this and find out if what
he says is accurate or not

Many thanks
Richard

Hi

I was watching this video by fastly ceo http://youtu.be/zrSvoQz1GOs?t=24m44s
he talks about the nginx ssl handshake versus apache and comes to the
conclusion that apache was more efficient at mass handshakes due to
nginx blocking while it calls back to openssl

I was hoping to get other people’s opinion on this and find out if what
he says is accurate or not

I would be interested in opinions/statements about this as well.

Regards,

Lukas

On Apr 20, 2014, at 21:17 , Lukas T. wrote:

I would be interested in opinions/statements about this as well.
nginx worker blocks on SSL handshake as well as on disk I/O. But in
contrast
to the disk I/O during the handshake you can not do anything else on
this CPU
at this time until CPU time share slice will end for the current
process/thread.
If a typical time share slice is 1ms and the 1024-bit key handshake time
is 0.5ms
then the chances that another process/thread is able to run on the same
CPU are 25%.
The lesser handshake time the lesser chances.


Igor S.
http://nginx.com

On Apr 21, 2014, at 12:46 , Igor S. wrote:

he says is accurate or not

I would be interested in opinions/statements about this as well.

nginx worker blocks on SSL handshake as well as on disk I/O. But in contrast
to the disk I/O during the handshake you can not do anything else on this CPU
at this time until CPU time share slice will end for the current process/thread.
If a typical time share slice is 1ms and the 1024-bit key handshake time is
0.5ms
then the chances that another process/thread is able to run on the same CPU are
25%.

Sorry, 50%.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs