-
-
Couldn't load subscription status.
- Fork 87
Description
Describe the bug
When running the client (or server) and the running app receives a Websocket message that is split over many frames CPU load is massive and it takes a very long time to parse the incoming frames concatenating the buffer and contract the message.
To Reproduce
- create a simple Vapor app with a websocket server
- create a WebSocket client (using this branch to that is can send large amounts of data Chunk Data/Text frames by outboundMaxFrameSize. #96)
- send a large amount of data to the server (a few MB is enough)
- Notice how the CPU load on the server spikes and it takes ages to handle the incoming data even through the client was able to send it all very quickly without any real CPU load.
Expected behavior
The server should be able to handle a multi frame ws message without completely locking up the cpu core at 100%.
Environment
MacOS (this happens with or without the #95)
- Vapor Framework version: 2.1.3
- Vapor Toolbox version: 18.3.3
- OS version: macOS 12.0 Beta (21A5284e)
Additional context
Running a profile suggesss that 71% of the cpu time is spent moving memory around.
and 28% is spend relocating the buffer

This seems related to the WebSocketFrameSequence.append method. It might well be better to make the WebSocketFrameSequence is it possible to create a ByteBuffer like object that just points to the underlying existing buffers rather than copies and decloates them?
