-
Notifications
You must be signed in to change notification settings - Fork 354
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CompositeByteBuf memory allocation for Frame messages #1066
Comments
@agusevas thanks for your investigation! I think the best way to go is to create a similar issue at the netty project and reference this one! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Motivation
I have been evaluating the RSocket and did some profiling. It looks like creating Frame message many
ByteBuf
buffers are used (i.e. header, payload, frame size). Those buffers are composed usingCompositeByteBuf
. TheByteBuf
can be reused, but theCompositeByteBuf
are always created as new ones. SuchCompositeByteBuf
allocation doesn't take much memory, but sending many Frame messages it sums up. Here is an example memory allocation using async-profiler:Also when Netty sends the Frame messages it needs to duplicate internal
DirectByteBuffer
objects because ofCompositeByteBuf
usage:This wouldn't be the case if only one
ByteBuf
were used instead.As far as I understand, it is done in order to avoid copying buffers. Nevertheless maybe there is a way of improving it?
Considered alternatives
Alternatives would be:
CompositeByteBuf
and just use oneByteBuf
per Frame message.SendUtils.sendReleasingPayload()
method and there is no way of replacing it.Additional context
I'm using
rsocket-java
version1.1.2
withTCP
transport.The text was updated successfully, but these errors were encountered: