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

[tarasko]

Current implementation of UVStream.write almost never sends data immediately. Instead the data is stored in the buffer and picked up later by uv_check callback.
This introduces unnecessary latency and CPU overhead.
Despite being a change only in UVStream it also directly benefit _SSLProtocolTransport.write latency since it uses UVStream.write to send ssl frames.

This PR increases RPS rate between echoclient and echoserver by roughly 10%.
echoclient --worker 1 --num 200000
echoserver --uvloop --proto

Because of this change a couple of test had to be tweaked.

• get_write_buffer_size cannot reliably return how much data has been already buffered. It doesn't take into account the socket send buffer (which is in the kernel)
• writing above limits does not necessarily cause pause_writing because again the data first goes to the socket send buffer

Please note that the current implementation of asyncio does the same thing. It tries to write directly to the socket, and, only if EWOULDBLOCK happens, the data is added to the buffer
https://github.com/python/cpython/blob/c13e7d98fb8581014a225b900b1b88ccbfc28097/Lib/asyncio/selector_events.py#L1065

[tarasko]

This also increases aiohttp websocket echo performance by 20-25%

[tarasko]

Hi @fantix, I saw you recently commited something to uvloop. Do you know if someone could take a look at this PR and maybe give a feedback?

[fantix]

Yeah I'll go through all issues/PRs again and include some in the final 0.21 release, it's just all taking some time unfortunately, thanks for the PR and your kind patience!

[tarasko]

Yeah I'll go through all issues/PRs again and include some in the final 0.21 release, it's just all taking some time unfortunately, thanks for the PR and your kind patience!

Hi @fantix, sorry to bother, I know it is open source, voluntary work and you're very busy. But would you have some time to look at this (and other my PRs) any time soon?

Also, 0.21.0 is already released :)

[Doch88]

Can someone from the contributors have a look at this PR? It would be nice to improve the performances!

[nevmerzhitsky]

@MagicStack guys please finish this CR.

[Doch88]

Updates on this? @fantix

[pedroconceicao]

@fantix are you planning to review and release this soon? 🙏

[Elyahou]

@1st1 Is there any news about this PR ?

[fantix]

Sorry about the delay! I'm back on this one now.

[fantix]

Actually instead of replicating the fast-path code, maybe we can just relax the fast-path condition, like:

@@ -424,7 +424,7 @@ cdef class UVStream(UVBaseTransport):
     cdef inline _initiate_write(self):
         if (not self._protocol_paused and
                 (<uv.uv_stream_t*>self._handle).write_queue_size == 0 and
-                self._buffer_size > self._high_water):
+                (self._buffer_size > self._high_water or len(self._buffer) == 1)):
             # Fast-path.  If:
             #   - the protocol isn't yet paused,
             #   - there is no data in libuv buffers for this stream,

(kind of a follow-up of 46dd8f3)

I believe this would have the same performance boost as this PR, yet being compatible with the current code base.

[fantix]

Actually call self._on_write() here?

[fantix]

I think we should also check self._protocol_paused and self._closed here?