Skip to content
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

Open
agusevas opened this issue Sep 5, 2022 · 1 comment
Open

CompositeByteBuf memory allocation for Frame messages #1066

agusevas opened this issue Sep 5, 2022 · 1 comment

Comments

@agusevas
Copy link

agusevas commented Sep 5, 2022

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 using CompositeByteBuf. The ByteBuf can be reused, but the CompositeByteBuf are always created as new ones. Such CompositeByteBuf allocation doesn't take much memory, but sending many Frame messages it sums up. Here is an example memory allocation using async-profiler:

CleanShot 2022-09-05 at 15 39 01@2x

Also when Netty sends the Frame messages it needs to duplicate internal DirectByteBuffer objects because of CompositeByteBuf usage:

CleanShot 2022-09-05 at 16 31 51@2x

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:

  • avoid using CompositeByteBuf and just use one ByteBuf per Frame message.
  • provide a way of customize the creation of Frame messages. Current implementation is using static SendUtils.sendReleasingPayload() method and there is no way of replacing it.

Additional context

I'm using rsocket-java version 1.1.2 with TCP transport.

@OlegDokuka
Copy link
Member

@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!
We can contribute to netty if needed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants