-
Notifications
You must be signed in to change notification settings - Fork 570
Improve SSL performance by avoiding SSLWantReadError exception and using much faster checks whenever possible #629
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
...oo unpredictable
andersfylling
commented
Nov 25, 2024
Can you expend on how you figured out it handles 99% of cases, and what are the last 1%?
99% - 1% is figurative. I don't know the real numbers and obviously it depends on a particular use case.
Checking incoming.pending > 0 or SSLObject.pending() > 0 may not help if we've received only a part of SSL frame. I think it may happen if system TCP stack broke it up or some receiving buffer was too small. In such case incoming.pending > 0 or SSLObject.pending() > 0 will be True but when we call SSLObject.read there will be SSLWantRead exception anyway.
In my use case client and server exchange a lot of small messages and every message (every SSL frame) can fit into a single TCP packet. Incoming data can also fit into all receiving buffers. So it never happens that uvloop reads only a part of SSL frame, it is always a complete frame, and SSLObject.read is able to process all incoming data.
Checking incoming.pending > 0 or SSLObject.pending() is very cheap comparing to raising and catching SSLWantRead. I think it would be always good if we can prevent SSLWantRead.
SSLWantReadError is expensive.
python/cpython#123954
This PR tries to predict that there will be SSLWantReadError by checking incoming.pending and SSLObject.pending() first.
This check works in 99% of cases. For the rest 1% we still rely on SSLWantReadError