Tornado Websocket write message performance degradation when binary is False about tornado HOT 2 OPEN

Just want to understand why there is an impact of 4.25x in performance when the size of message is just increased by 1.4x.

It seems likely that you're hitting a 128KB socket send buffer (SO_SNDBUF). The first N bytes written to a socket will appear to be instantaneous, but once that buffer is full, no more can be sent until we've received an ACK from the other side of the connection. This can show up as time spent in epoll (but be careful, because epoll is a shared resource across all connections in the process - generally when you're profiling an async application you should ignore epoll time; it's what the server is doing when it's idle).

When binary is true the amount of time consumed in epoll is almost negligible and it doesn't seem to be having any performance difference based on the size of string as well.

This is surprising - there's almost no difference on the write path between binary and text messages - just a call to str.encode(). Everything at the network level should be equivalent. Is everything but the binary flag the same in these tests?

from tornado.

Thanks for responding.
@bdarnell

I have shared the epoll impact particulary because, I have done profiling at that one line of code which writes data to encode and observed the impact on epoll,
await client["client"].write_message(frame_data, is_binary)
I did profliling on this very exact line.

The size change doesn't seem to affect is_binary as true and it does only when is_binary is false in the above case everything else is exactly same in the enviroment.

from tornado.