GeezerVison

The World Wide Web, restored to 800 pixels of glory.

GeezerVison is showing github.com — Improve SSL performance by avoiding SSLWantReadError exception and using much faster checks whenever possible by tarasko · Pull Request #629 · MagicStack/uvloop

Conversation

tarasko commented Sep 11, 2024

Copy link

Copy Markdown

Contributor

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

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Tapanhaz and Vizonex reacted with heart emoji

All reactions

❤️ 2 reactions

taras added 9 commits

September 9, 2024 16:00


          Refactor and optimize buffered reads

f18d1a3


          Refactor ssl buffered reads

951e8df


          Fix tests

26ede3c


          WIP: still broken, seems it is not possible cause SSLObject.read is t…

eb7ce66

…oo unpredictable


          Cleanup

473214b


          Fix comments

62272e1


          Cleanup

7b1f810


          Cleanup

a73d44e


          Remove unintented change

1078fc2

tarasko changed the title ~~Improve performance of ssl reads~~ Improve SSL performance by avoiding SSLWantReadError exception and using much faster alternative whenever possible

Oct 15, 2024

tarasko changed the title ~~Improve SSL performance by avoiding SSLWantReadError exception and using much faster alternative whenever possible~~ Improve SSL performance by avoiding SSLWantReadError exception and using much faster checks whenever possible

Oct 15, 2024

tarasko mentioned this pull request

Nov 25, 2024

Update performance plot #566

Closed

andersfylling commented Nov 25, 2024

Copy link

Copy Markdown

Can you expend on how you figured out it handles 99% of cases, and what are the last 1%?

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

tarasko commented Nov 25, 2024 •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Contributor Author

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.

gpshead, Vizonex, and Tapanhaz reacted with thumbs up emoji

All reactions

👍 3 reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

tarasko mentioned this pull request

Dec 26, 2024

Inefficient ssl.SSLWantReadError exception slows down very common use-case python/cpython#123954

Open

tarasko mentioned this pull request

Jan 14, 2026

Improve performance and reduce latency of Transport.write by attempting to send data immediately if all write buffers are empty #619

Merged


          Merge branch 'master' into optimize_ssl_read_latency

5971ab7

fantix approved these changes

Jan 27, 2026

View reviewed changes

fantix left a comment

Copy link

Copy Markdown

Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good one!

Though, it's trickier to verify correctness than just SSLWantReadError, because SSLObject.read() may also raise SSLWantWriteError during close_notify and re-negotiation. The two points to verify are:

If SSLObject.read() should be called regardlessly per _do_read().
If SSLObject.read() should be called regardlessly per loop within _do_read().

(1) is triggered by I/O read event or user calling transport.resume_reading(). In such scenarios, I don't see a case where the SSLObject has a pending state that requires read() to handle, if both buffers are empty.

(2) is where this optimization happens. It challenges the SSLObject state machine assumption, which is, to call read() until it returns 0, or raises an error. In other words, if a first read() call didn't return 0 or raise an error, can we safely skip the next read() call if both buffers are empty? Reading the underlying C code, I don't see any state left behind. And our use case here (sslproto.pyx) doesn't have other changes to the SSLObject state during _do_read(). Also, given that our sophisticated test cases are passing, I believe it's safe to apply this optimization.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

Comment thread

uvloop/sslproto.pyx Outdated

		else:

		last_bytes_read = <Py_ssize_t>self._sslobj_read(
		app_buffer_size, app_buffer)

fantix Jan 27, 2026

Copy link

Copy Markdown

Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

	app_buffer_size, app_buffer)
	app_buffer_size - total_bytes_read, app_buffer)

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

tarasko Jan 27, 2026

Copy link

Copy Markdown

Contributor Author

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good one. Fixed!

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

tarasko Jan 27, 2026

Copy link

Copy Markdown

Contributor Author

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, probably doesn't make a difference because SSLObject.read won't read more than the length of app_buffer and it is already app_buffer_size - total_bytes_read. I fixed it anyway for consistency

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

fantix and Tapanhaz reacted with thumbs up emoji

All reactions

👍 2 reactions

tarasko Jan 27, 2026

Copy link

Copy Markdown

Contributor Author

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this whole SSLWantWriteError from SSLObject.read is tricky.

I'm not 100% sure but I have the following assumption:

Python ssl.MemoryBIO grows dynamically without fixed capacity, has no limit, write can only fail in case of system out-of-memory
SSL_read_ex returns SSL_WANT_WRITE_ERROR when memory BIO runs out of memory, not when we just wrote something. So given (1) SSL_WANT_WRITE_ERROR may only happen when the system runs out of memory.
SSL_read_ex does use its chance to write control stuff right after successful read before returning. link

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

Comment thread

uvloop/sslproto.pyx Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread

uvloop/sslproto.pyx

Comment on lines +731 to +732

		if app_buffer_size == 0:
		return

fantix Jan 27, 2026

Copy link

Copy Markdown

Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh, good catch! This fixes a false EOF bug in previous code I think. Would be nice to have a test!

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

tarasko and Tapanhaz reacted with thumbs up emoji

All reactions

👍 2 reactions

taras and others added 2 commits

January 27, 2026 20:18


          Apply suggestions from PR review

4434c63


          Merge branch 'master' into optimize_ssl_read_latency

27d0693

fantix approved these changes

Jan 30, 2026

View reviewed changes

fantix merged commit a308f75 into MagicStack:master

Jan 30, 2026

17 checks passed

Uh oh!

There was an error while loading. Please reload this page.

tarasko deleted the optimize_ssl_read_latency branch

January 31, 2026 21:44

fantix mentioned this pull request

Sep 30, 2026

uvloop 0.23.0 #768

Merged

jensbjorgensen pushed a commit to jensbjorgensen/uvloop that referenced this pull request

Oct 6, 2026


          uvloop 0.23.0

c5f7deb

Changes
=======

* Add Python 3.15 and 3.15t wheel builds and CI coverage (MagicStack#758)
  (by @honglei @fantix in f7c0547)

* Add support for the `eager_start` keyword argument in create_task() (MagicStack#748)
  (by @samypr100 in 3cbb095 for MagicStack#746 MagicStack#718)

* Add thread name prefix to the default thread pool executor (MagicStack#636)
  (by @inikolaev @fantix in 0582f94 for MagicStack#562)

* Add support for special hostname `<broadcast>` (MagicStack#592)
  (by @jpbede in 3060ceb for MagicStack#540)

* Upgrade libuv to v1.52.1 (MagicStack#753)
  (by @fantix in e8efea4 for MagicStack#752)

* Improve performance by using Python C API to enter/exit context (MagicStack#627)
  (by @tarasko in 837ef22)

* Improve performance/latency of Transport.write (MagicStack#619)
  (by @tarasko in 1d9b6e0)

* Replace some SSL vectorcall with direct methods (MagicStack#626)
  (by @tarasko in 6a27cbe)

* Optimize SSL buffered reads using C values (MagicStack#629)
  (by @tarasko in a308f75)

Fixes
=====

* Detach socket on create_connection cancellation to prevent fd double-close (MagicStack#740)
  (by @junjzhang @fantix in dc680eb for MagicStack#645 MagicStack#738)

* Remove `loop._ready_len` in favor of `len(loop._ready)` (MagicStack#721)
  (by @x42005e1f in 5910a18 for MagicStack#720)

* Prefer inspect.iscoroutinefunction (MagicStack#705)
  (by @MatthieuDartiailh in fd65027 for MagicStack#703)

* Fix context tests by explicitly yielding after run_in_executor (MagicStack#743)
  (by @samypr100 in 6cd24cb)

* Fix test_create_connection_open_con_addr with Python 3.13.9+ (MagicStack#713)
  (by @shadchin in b93141a for MagicStack#701)

* Skip flaky test_cancel_post_init on asyncio 3.13+ (MagicStack#714)
  (by @fantix in 3ea5c85 for MagicStack#709)

* Fix flaky test_fs_event (MagicStack#717)
  (by @fantix in 8da4547)

* Use C __atomic builtins for debug counters (MagicStack#719)
  (by @fantix in 836e3b2)

* Update the example to work with Python 3.14 (MagicStack#710)
  (by @Jamie-Chang in b74c2f1)

Build
=====

* Replace pkg_resources with packaging and use Cython 3.1 (MagicStack#742)
  (by @samypr100 in b377b7c for MagicStack#729)

* Remove wheel as a build dependency (MagicStack#696)
  (by @DimitriPapadopoulos in 173e88c)

* Support any number of flags in UVLOOP_OPT_CFLAGS (MagicStack#630)
  (by @mgorny in 963a5f3)

Reviewers

fantix

fantix approved these changes

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Uh oh!

There was an error while loading. Please reload this page.

3 participants

Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.

GeezerVison

Conversation

tarasko commented Sep 11, 2024

Uh oh!

andersfylling commented Nov 25, 2024

Uh oh!

tarasko commented Nov 25, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fantix left a comment

Choose a reason for hiding this comment

Uh oh!

fantix Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

tarasko Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

tarasko Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

tarasko Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

fantix Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

tarasko commented Nov 25, 2024 •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.