[openssl-dev] [openssl.org #3528] [PATCH] ssl: SSL_MODE_ASYNC_KEY_EX

[Matt Caswell]

On 06/02/16 04:24, Fedor Indutny via RT wrote:
> On Fri, Feb 5, 2016 at 7:14 PM, Matt Caswell <matt at openssl.org> wrote:
> 
>>
>>
>> On 05/02/16 22:42, Fedor Indutny wrote:
>>> Matt,
>>>
>>> I have looked through the APIs. Will have to experiment with them
>>> somewhen later to see how well they will perform, but from theoretical
>>> point of view I am a bit scared of having 2 fds (and one ucontext) for
>>> every job in a pool. It seems like this could be a bit of burden in
>>> event-loop based model. For example, it is not hard to imagine a
>>> situation in node.js application with 10000 handshakes that are trying
>>> to complete in parallel. Is there any need in creating this fds
>>> unconditionally?
>>
>> Well of course the number of jobs in the pool is not the same as the
>> number of handshakes. We create a pool of jobs that are shared between
>> the handshakes as required in order to conserve resources. With regards
>> to the fds, I mentioned that I was working on some tweaks to the API. It
>> is in this area where there are tweaks being made. Specifically I am
>> moving the creation of the fds to be a responsibility of the called code
>> (i.e. most likely an engine) and not the async framework itself.
>>
> 
> I understand what the pool means ;) The imaginary situation that I was
> talking about had lots of handshakes happening in parallel. To make it a
> bit real: a server that decrypts premaster secrets remotely with 2000ms
> latency, that receives 1000 requests per second. In such situation pool
> size needs to be at least 2000 to accommodate this amount of requests.
> 
> While 2000ms is a bit far-fetched, it is very easy to imagine that that
> remote decrypting server will go absolutely down and won't respond at
> all. Meaning that for some period of time (maybe 5-10 seconds) all this
> load is going to attempt to take new job from the pool. While I'm sure that
> SSL structures itself will take a huge stake in resources usage, having
> extra fd for each of these jobs doesn't sound right to me.

Right, but you can set a maximum size limit on the pool if that is
something you are worried about. I would expect you would size it to the
amount of jobs that your "remote decrypting server" (as you call it...I
think of it as an engine) can handle, plus possibly a bit more if you
are willing to have some kind of queue in the engine itself.

You are of course right that there will be a limit where you attempt to
throw so much load at something that it's not going to be able to take
any more. Handshakes will start failing at that point. That's no
different to the situation today of course. If you throw enough load at
OpenSSL today, sooner or later you will hit the limits of the hardware.

Matt