<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 5, 2016 at 7:14 PM, Matt Caswell <span dir="ltr"><<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 05/02/16 22:42, Fedor Indutny wrote:<br>
> Matt,<br>
><br>
> I have looked through the APIs. Will have to experiment with them<br>
> somewhen later to see how well they will perform, but from theoretical<br>
> point of view I am a bit scared of having 2 fds (and one ucontext) for<br>
> every job in a pool. It seems like this could be a bit of burden in<br>
> event-loop based model. For example, it is not hard to imagine a<br>
> situation in node.js application with 10000 handshakes that are trying<br>
> to complete in parallel. Is there any need in creating this fds<br>
> unconditionally?<br>
<br>
</span>Well of course the number of jobs in the pool is not the same as the<br>
number of handshakes. We create a pool of jobs that are shared between<br>
the handshakes as required in order to conserve resources. With regards<br>
to the fds, I mentioned that I was working on some tweaks to the API. It<br>
is in this area where there are tweaks being made. Specifically I am<br>
moving the creation of the fds to be a responsibility of the called code<br>
(i.e. most likely an engine) and not the async framework itself.<br></blockquote><div><br></div><div>I understand what the pool means ;) The imaginary situation that I was</div><div>talking about had lots of handshakes happening in parallel. To make it a</div><div>bit real: a server that decrypts premaster secrets remotely with 2000ms</div><div>latency, that receives 1000 requests per second. In such situation pool</div><div>size needs to be at least 2000 to accommodate this amount of requests.</div><div><br></div><div>While 2000ms is a bit far-fetched, it is very easy to imagine that that</div><div>remote decrypting server will go absolutely down and won't respond at</div><div>all. Meaning that for some period of time (maybe 5-10 seconds) all this</div><div>load is going to attempt to take new job from the pool. While I'm sure that</div><div>SSL structures itself will take a huge stake in resources usage, having</div><div>extra fd for each of these jobs doesn't sound right to me.</div><div><br></div><div>I'm glad to hear that this fd-behavior is going to be overridable. This</div><div>sounds lovely!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> However, again, this is only a hypothetical situation, I'm yet to see<br>
> how well it will behave in real situations. Just sharing some immediate<br>
> concerns with you.<br>
<br>
</span>I have been collaborating with Intel on this piece of work and they have<br>
been testing the performance quite thoroughly. We are still working on<br>
optimising things, but so far so good.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Fantastic!</div><div><br></div><div>Thank you very much,</div><div>Fedor.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
Matt<br>
</font></span><span class=""><br>
<br>
><br>
> Thank you,<br>
> Fedor.<br>
><br>
> On Thu, Feb 4, 2016 at 4:56 AM, Fedor Indutny via RT <<a href="mailto:rt@openssl.org">rt@openssl.org</a><br>
</span><span class="">> <mailto:<a href="mailto:rt@openssl.org">rt@openssl.org</a>>> wrote:<br>
><br>
>     Thank you very much, Matt, Rich.<br>
><br>
>     I will read through these docs tomorrow.<br>
><br>
>     On Thu, Feb 4, 2016 at 4:29 AM, Matt Caswell via RT <<a href="mailto:rt@openssl.org">rt@openssl.org</a><br>
</span><span class="">>     <mailto:<a href="mailto:rt@openssl.org">rt@openssl.org</a>>> wrote:<br>
><br>
>     ><br>
>     ><br>
>     > On 04/02/16 06:34, Salz, Rich via RT wrote:<br>
>     > > It’s late and my response was incomplete.<br>
>     > > The other part has already landed in master, and that's the "async<br>
>     > engine" support.<br>
>     ><br>
>     > See:<br>
>     ><br>
>     > <a href="https://www.openssl.org/docs/manmaster/crypto/ASYNC_start_job.html" rel="noreferrer" target="_blank">https://www.openssl.org/docs/manmaster/crypto/ASYNC_start_job.html</a><br>
>     > <a href="https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_mode.html" rel="noreferrer" target="_blank">https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_mode.html</a> (i.e.<br>
>     > the SSL_MODE_ASYNC bit)<br>
>     > <a href="https://www.openssl.org/docs/manmaster/ssl/SSL_waiting_for_async.html" rel="noreferrer" target="_blank">https://www.openssl.org/docs/manmaster/ssl/SSL_waiting_for_async.html</a><br>
>     ><br>
>     > I'm working on a patch that may make some tweaks to this API, but you<br>
>     > should get the idea.<br>
>     ><br>
>     > Matt<br>
>     ><br>
>     ><br>
>     ><br>
><br>
>     _______________________________________________<br>
>     openssl-dev mailing list<br>
>     To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br>
><br>
><br>
><br>
><br>
</span>--<br>
<div class="HOEnZb"><div class="h5">openssl-dev mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br>
</div></div></blockquote></div><br></div></div>