Hi!
I found strange performance issue with akka http websocket client.
I have a server written using akka http server which works fine. For testing purposes I created a dummy client app that uses akka http websocket client and just consume and drain data from the server. Unfortunately I observed that the consumer app can not handle the load. Server sends somewhere around 20K objects of size ~500 bytes each per second while client is able to consume only 5K. I also did implement another client app using netty and this app worked completely fine.
Any ideas regarding this situation?
Also one more thing which I’ve realised (maybe it is related somehow). I observed BinaryMessage.Streamed quite often even though I would not expect them. I mean all my messages are quite small and I send them as BinaryMessage.Strict. I understand that rfc6455 allows receivers to decide how to consume data (buffer all content before consuming or stream it), but maybe these streamed messages affect the performance?
Your hunch about streamed messages might be correct. Could you run with a profiler to verify that this is what’s going on? For quick testing it would also suffice to run jstack <pid> a few times and attach the output here.
It’s somewhat unexpected that you would see lots of streamed messages because these should only be created if a message is broken up into several parts (usually because of being chopped up in networking buffers). Usually, when the reader of the message is slow the messages should be buffered up and make it less likely that they received in multiple chunks, especially if the messages are as small as yours.
I think you got sbt instead of the application for the stack traces. But I think it’s not necessary any more, in the ticket I found a few places where we could optimize things. So far, the WS implementation hasn’t been heavily optimized.