You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi all,
At my current job I'm using aiohttp websockets to subscribe to updates from a 3rd party webserver. The traffic consists of a lot of
small update messages and is very spiky in nature. Also only the very last update usually matters, all previous updates can be often just ignored.
The client is very sensitive to message processing delays. I have already cythonized the critical path in business logic and that gave great results. The bottleneck now is within ClientWebSocketResponse + FlowControlDataQueue
I see a few performance issues there:
FlowControlDataQueue internals are private, there is no way to see if more message have been already received and are just waiting in the queue. If there are 20 messages in the queue, I don't need all of them, only the last one.
FlowControlDataQueue, can potentially pause reading. There is no way to monitor, control or turn it off.
ClientWebSocketResponse.receive setup timeouts, creates and set result on a future even if there are more messages in FlowControlDataQueue. That's unnecessary.
I believe cythonizing WebSocketReader would help. parse_frame seems to be a great candidate for cythonization. I would also cythonize and include into distribution a pxd for WSMessage type and relevant enums
Ideally, would be great if I could pass my own WSMessage handler with a simple non-async on_ws_message callback and bypass the whole ClientWebSocketResponse + FlowControlDataQueue logic. Instead of optimizing ClientWebSocketResponse, I would rather have such a low level interface.
Something similar to Protocol.data_received, Protocol.eof_received from asyncio. These are low-level non-async callbacks. Would be nice to have something similar for websockets.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi all,
At my current job I'm using aiohttp websockets to subscribe to updates from a 3rd party webserver. The traffic consists of a lot of
small update messages and is very spiky in nature. Also only the very last update usually matters, all previous updates can be often just ignored.
The client is very sensitive to message processing delays. I have already cythonized the critical path in business logic and that gave great results. The bottleneck now is within ClientWebSocketResponse + FlowControlDataQueue
I see a few performance issues there:
FlowControlDataQueue internals are private, there is no way to see if more message have been already received and are just waiting in the queue. If there are 20 messages in the queue, I don't need all of them, only the last one.
FlowControlDataQueue, can potentially pause reading. There is no way to monitor, control or turn it off.
ClientWebSocketResponse.receive setup timeouts, creates and set result on a future even if there are more messages in FlowControlDataQueue. That's unnecessary.
I believe cythonizing WebSocketReader would help. parse_frame seems to be a great candidate for cythonization. I would also cythonize and include into distribution a pxd for WSMessage type and relevant enums
Ideally, would be great if I could pass my own WSMessage handler with a simple non-async on_ws_message callback and bypass the whole ClientWebSocketResponse + FlowControlDataQueue logic. Instead of optimizing ClientWebSocketResponse, I would rather have such a low level interface.
Something similar to Protocol.data_received, Protocol.eof_received from asyncio. These are low-level non-async callbacks. Would be nice to have something similar for websockets.
Beta Was this translation helpful? Give feedback.
All reactions