Skip to content

Pooled memory management currently impossible with socket.io interface #5353

Open

Description

@bytenik

Is your feature request related to a problem? Please describe.
Currently, my application maintains reasonably large Buffer objects in a pool, reusing them to avoid tons of GC contention. However, socket.io is a bit of a black hole for those buffers. Once we .emit one, we don't know when it has been actually sent to the client and "released" from socket.io. Thus we cannot reuse those buffers and they must be GC. We're spending upwards of 60% of our CPU time in GC on these objects we send to socket.io right now.

Describe the solution you'd like
I would like socket.io to expose a released event that is emitted every time socket.io has successfully sent an object to the client. It would contain as its body the object that was released. These could be buffers, classes, POJO, etc., anything that lives on the heap and socket.io is now done with.

Describe alternatives you've considered
I don't see any alternatives at this time.

Additional context
I'd be very happy to implement this feature myself but before I spend time on it, I want to know that the solution I proposed is acceptable and the PR would likely to be merged.

Activity

  1. bytenik commented on Jun 10, 2025

    @bytenik
    ContributorAuthor

    @darrachequesne is this something you would be open to?

  2. darrachequesne commented on Jun 11, 2025

    @darrachequesne
    Member

    Hi!

    Could the drain event of the low-level connection fit your use case?

    io.on("connection", (socket) => {
      socket.conn.on("drain", () => {
        // clean up
      });
    });

    Reference: https://socket.io/docs/v4/server-api/#socketconn

  3. bytenik commented on Jun 13, 2025

    @bytenik
    ContributorAuthor

    @darrachequesne No; that happens when the low-level buffer that's internalized to the socket is drained. It doesn't happen when socket.io is done with the buffer because it has been placed into that TCP buffer.

  4. bytenik commented on Jun 16, 2025

    @bytenik
    ContributorAuthor

    @darrachequesne sorry to ping again and poke, but this is a huge issue at my company and I'm mostly just looking for your acknowledgement that you find my approach acceptable. At that point I'll start working on it. I would rather not develop something that then turns into a patch I have to apply to socket.io forever on my server.

  5. darrachequesne commented on Jun 17, 2025

    @darrachequesne
    Member

    Yes, that sounds like a reasonable use case 👍 could you please open a PR?

  6. bytenik commented on Sep 19, 2025

    @bytenik
    ContributorAuthor

    Hi @darrachequesne, the PR has been opened now with no engagement for several months. Can we do something to resolve this and get it merged?

  7. darrachequesne commented on Sep 19, 2025

    @darrachequesne
    Member

    Hi!

    Sorry for the delay. To be honest, I think the suggested change needlessly complicates the source code, for a really specific use case, which is why I'm not sure about merging it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions