Opened 11 years ago

Last modified 11 years ago

#4848 enhancement new

Run TLS/SSL handshakes in thread pool

Reported by: Itamar Turner-Trauring Owned by:
Priority: low Milestone:
Component: core Keywords: performance
Cc: Branch:
Author:

Description

The most expensive part of SSL and TLS is the initial handshake. In order to take advantage of multiple processors, and reduce blocking under high load, it would be good to do the handshake in a separate thread than the reactor.

(Doing this for the ongoing payload de/encryption is a bit less of an obvious win because of the added latency, but perhaps we might want a ticket for that as well, or expand this ticket to cover that.)

Change History (4)

comment:1 Changed 11 years ago by Glyph

It's worth noting that if someone wants to tackle this, exarkun has been doing some benchmarking lately that indicates that our reactor implementation of SSL is entirely a waste of code, and twisted.protocols.tls is actually a little faster than reactor.listenSSL. I think this is relevant to this ticket because I think that it would be considerably easier to implement this kind of pooling with that implementation, since it's a bit more straightforward to figure out how data is being passed around (as it's just an IProtocol.

Anyway, it should also be said: step 1 is to make sure that any change like this yields an improvement on some benchmark. Benchmarks can be found here, for now: https://code.launchpad.net/~exarkun/+junk/twisted-benchmarks

comment:2 Changed 11 years ago by <automation>

comment:3 Changed 11 years ago by Jean-Paul Calderone

Something to be careful of here is whether we cause pyOpenSSL Context callbacks to be invoked in a non-reactor thread. There are two callbacks that this might affect now, the certificate verification callback and the info callback. There may be more in the future, such as the server name callback (necessary for us to implement #4887).

To this point, these callbacks will all have been called in the reactor thread. As far as I know, they'll be called beneath do_handshake, so we may need to make the behavior of calling that method in a non-reactor thread opt-in for people who know their callbacks are thread safe.

We could avoid this if we had a better SSL API which let us separate the expensive crypto part of the handshake from the cheap policy decision parts of the handshake. However, I don't think we'll be able to do that with OpenSSL.

comment:4 in reply to:  3 Changed 11 years ago by Glyph

Replying to exarkun:

To this point, these callbacks will all have been called in the reactor thread. As far as I know, they'll be called beneath do_handshake, so we may need to make the behavior of calling that method in a non-reactor thread opt-in for people who know their callbacks are thread safe.

I believe all of these callbacks need to be implemented synchronously anyway, so it's pretty unlikely that they'll want to call reactor APIs. I hope that as part of #4887 (and others), we expose an interface that would already implement the actual callback somewhere in the twisted.internet.ssl namespace, which would already appropriately registered themselves as threadsafe.

Note: See TracTickets for help on using tickets.