kazuho
Joined 14 years ago
Karma
568
Submissions
56
Member since
May 31
http://blog.kazuhooku.com/
https://github.com/kazuho/
View on Hacker NewsRecent submissions
Comment · 11 years ago
It is true that RSA operation over IPC is slower than doing it internally. But the latter is by magnitudes faster than the former, therefore the slowdown is negligible in practice.
You can find the numbers in the FAQ section of the linked website.
Comment · 11 years ago
Wrong.
You seem to have confusion between TLS handshakes and RSA operations.
In OpenSSL (which is used by many servers including node.js, nginx), RSA operation is always synchronous. Therefore, using Neverbleed does not impose new limits regarding concurrency.
Comment · 11 years ago
I assume you are referring to Keyless SSL.
https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-tec...
For Keyless SSL, it is necessary to make RSA operations asynchronous, since the operations are requested over the TCP network (which may have big delays).
OTOH Neverbleed degelates the operations within the same server using Unix sockets. So there is no fear of such delays. And the server spawn a dedicated thread to each client thread. In other words, the delay is practically _no worse_ than what it is without Neverbleed.
And discussing _how worse_ it is, calculations related to TLS handshakes may block the server for a few milliseconds. It may sound bad, but generally speaking it is negligible comparing to the latency over a public network.
Comment · 11 years ago
Libh2o (the protocol implementation) support both libuv and evloop (our tailor-made event loop).
The default event loop of libh2o is libuv, since libuv is popular and has bindings to other protocols (which you would need if you want to implement an application using libh2o).
OTOH the standalone server uses evloop for performance.
Comment · 11 years ago
Thank you for your comment.
I doubt if anybody is using the mruby handler in production, considering the fact that functions necessary to modify the requests in the handler was committed this week :-)
Comment · 11 years ago
Unfortunately the block was always found on the test machine. The test was conducted using a VM running running on a host on which the web browsers were run, so there were no noise or packet loss; the results were reproducible.