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

Support Action<ReadOnlySpan<byte>> for statistics callbacks #2412

Open
fabianoliver opened this issue Feb 11, 2025 · 0 comments
Open

Support Action<ReadOnlySpan<byte>> for statistics callbacks #2412

fabianoliver opened this issue Feb 11, 2025 · 0 comments

Comments

@fabianoliver
Copy link

Idea

currently, ConsumerBuilder only allows to registers statistics callbacks as Action<string> .

Would it be possible to allow alternatively registering an Action<ReadOnlySpan<byte>> , which would receive a span of the raw UTF8 string bytes from librdkafka's native memory? Is that something the team would be interested in implementing, and/or willing to accept a PR for it?

Motivation

Quite often, consumers likely aren't interested in the raw string, but would deserialize its JSON contents. System.Text.Json these days works very well based on deserializing raw spans of UTF8 bytes without the need to turn things into a string beforehand.

Avoiding the string allocation would be particularly convenient as the statistics string can be quite large - it tends to be around ~64kb in UTF8 bytes from the samples I've looked at, so roughly 128kb for the actual (UTF-16) c# string. Meaning its quite large, and arguably even worse, large enough to consistently land on the LOH.

This could make a fairly measurable difference - for example, one of the apps I'm running is reliant on running quite a few kafka consumers (I'm aware of the general recommendation to run only 1 consumer per app; however, I've found significant throughput benefits of running several, without having been able to figure out a config for only 1 consumer that would get close). Each of those consumers currently subscribes to statistics every 1000ms. The app ended up allocating almost 8 mb/sec (in the LOH no less) just for statistics callbacks, in spite of only needing to parse/deserialize a tiny subset of the statistics JSON string for the parts it actually cares about. If we had a way of receiving the raw UTF8 bytes, these allocations could almost entirely be avoided.

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

1 participant