[winrid]

EDIT - it seems maybe I was wrong here

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...)

[WatchDog]

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.

[winrid]

Here's what I was thinking of, under "Vert.x Memory Usage": https://www.tikalk.com/posts/2018/04/30/vertx-memory-usage-w...

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.

[WatchDog]

FWIW, here is a fairly minimal example[0] of broadcasting over websockets reusing the same buffer.

I'm not very familiar with vert.x(not a netty expert either), but I think the author of that article is ascribing blame to the wrong place.

[0]: https://github.com/juggernaut/netty-websocket-broadcast-exam...

[winrid]

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)

[mycall]

> zero-copy capable byte buffer

This is similar to .NET Standard 2.1 Span<T>?