Netty copies the response body when sending to each client, so it's not as lightweight as I've found. For streaming large response bodies, it does not work well. I haven't found a good Java alternative yet (probably will switch to C++ and uWS...)
Netty core is about as close to the metal as networking gets on the JVM.
It's abstractions are built over a zero-copy capable byte buffer, and there is generally a lot of care taken to avoid copying where possible.
I haven't used the websocket codec, but I'm sure the maintainers would welcome a patch that removes unnecessary copying.
Quote:
"But how does Netty do things so fast ? One of the reasons is that it is using native memory pool to store network buffers. If you did some file reading or network action with Vert.x you probably used io.vertx.core.buffer.Buffer class. This class is actually a wrapper around Netty io.netty.buffer.ByteBuf class. Why am I telling you all this ? Let assume that you have a service where clients are downloading 20Mbyte files. Netty will have to allocate at least 20Mbyte for every connected client."
Although this may be an issue with how Vert.x is using Netty. I have to dig into it more.
Not using websockets, but thanks! I have to look into it again. Right now the service is working fine so I haven't been motivated to work on it again. (in-memory CDN based on vertx-web + Caffeine + custom on-disk LRU cache)
I'm not on the engineering team so can't speak to the cost/benefit, but it seems to have been a pretty successful transition.