Background:

SSLSocket.read drops the GIL and performs exactly one successful call to  OpenSSL's `SSL_read`, whose documentation states "At most the contents of one record will be returned". TLS records are at most 16KB, so high throughput (especially multithreaded) TLS reception can become bottlenecked on the GIL.

Proposal:

For non-blocking sockets, call SSL_read in a loop until the user-supplied limit is reached or no bytes are available on the socket. I don't know of a way to safely improve performance for blocking sockets.

Initial testing:

I performed initial testing using 32 threads pinned to 16 cores, downloading and re-assembling a single 140270MB file from a "real world" TLS sender. This resulted in a 4x increase in throughput, a 6.6x reduction in voluntary context switches, a 3.5x reduction in system time. User time did increase by 43%, so the overall reduction in CPU usage was only 2.67x.

                                 before     after
     wall clock time (s)    :    29.637     7.116
     user time (s)          :     8.793    12.584
     system time (s)        :   105.118    30.010
     user + system time (s) :   113.911    42.594
     cpu utilization (%)    :       384       599 
     voluntary switches     : 1,653,065   248,484
     speed (MB/s)           :      4733     19712

My git branch (currently a draft) is at https://github.com/hashbrowncipher/cpython/commits/faster_tls

Amazing! Would you consider making a pull request out of your branch?

re: `PyErr_HasSignals` is a notable addition to the cpython API, it may need discussion, and (imo) documentation.

Josh, could you please rebase your branch and create a pull request? The PR process will verify that you have submitted a CLA.

It would be very beneficial if this gets added. In our application (usenet client) I have wondered for years why we had to limit ourselves to 16k blocks and have such lower speeds compared to non SSL connections.

The PR is still experimental and only applies to one direction. I doubt that it will be ready, reviewed, and approved for feature freeze of 3.10.

Understandable, as the feature freeze was yesterday :)

Just like to note that we have a 100.000 or so users (which I know is very little compared to overal number of Python users) of our application that this could really help.
 
We have used a lot of CPU cycles over the past year doing many repeated 'recv(16384)' for SSL-sockets.

Thank you!

You could try to convince Pablo. He is the release manager for 3.10. He can grant exceptions.

I also included Benjamin, Nathaniel, and Victor in the nosy list. They have a deeper understanding of the network I/O layer than me. I mostly take care of the crypto and X.509 part of the module.

Is anyone available to give feedback on the remaining questions/problems in the PR?

I don't want to be pushy and if it's only changed in 3.11, I understand, but just hoping for some progress :)
Also willing to dive into it myself, but not a network/python-core specialist to really get all the details right away.

Could the new PR be reviewed? Thank you!
https://github.com/python/cpython/pull/31492
Documentation still needs updating, but would like feedback.

PS: Why not enable the setting the GitHub Actions workflow only need to be approved for new GitHub accounts instead of for *all* new contributors?

Pinging in hope for a review on https://github.com/python/cpython/pull/31492

We have very few people that are familar with ssl module and especially with its I/O layer. I'm busy with other topics. Others are directly affected by war in Ukraine.

I'm not a particular fan of the new "eager_recv" property introduced by your PR. Also the improvement should be implemented for read and write ops.

Implementing for write is not needed as OpenSSL's SSL_write_ex that is used by write() already writes the whole buffer at once. Only reading OpenSSL does in the 16k segments.

The new option was introduced to prevent the compatibility problems for code that would not expect the EOF being read in a sinhle read(), as Josh explained in his initial PR. This way the faster (but breaking) behavior can be enabled explicitly. 

The info is also in the PR, in case there is time to review in the future.