Everything you do is based on a WebSocket message. reading and writing.
Per RFC6455, a WebSocket message has no upper limit in size, only the individual frames do.
A WebSocket message is 0..n frames. a frame can be 0 to 9,223,372,036,854,775,807 bytes in size (63-bit value btw).
In Jetty, we obviously can't support that with modern hardware (who has 9 exabytes of memory on their computer??)
Outgoing messages are not checked, as it should be obvious to you if you can handle it or not.
Dealing with Extensions:
The need to support RFC6455 WebSocket extensions means we have a layer between the WSE and the physical connection called the ExtensionStack.
This complicates matters as the extensions can change the framing, the number of frames, etc, making the traditional approach of read/write to the physical connection from the WSE impossible.
Performance with Jetty 9.0.3:
We've done some simple (really simple) load testing on WebSockets.
On a simple test of 1000 active WebSockets we got an average rate of 200,000 messages a second per socket.
But we need MUCH more testing here, along with paying attention to memory and CPU, not just I/O.
The cometd project has already embraced Jetty 9's WebSocket and have been testing the performance from their point of view, while they have some concerns with memory (the jetty websocket implementation seems to have frequent, but small, GC behavior), overall they are happy with what they see.