Handle Deserialization off of Transport Threads if Action is Forking #66828
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We can push deserialization off to the handling threadpool instead of doing it on the transport threads when forking anyway. In case of very large messages like bulk request that can take on the order of a second to fully deserialize this prevents clusters from becoming unstable because transport threads become randomly blocked on this kind of deserialization work. Also, on balance this change could reduce load from GC because we trade longer lived buffers that are cheap to recycle for shorter lived concrete deserialized transport messages. On the flipside of things, for smaller messages the overhead from keeping buffers for longer (buffer page size > message size) increases memory use in some cases potentially.
original-brownbear
added
>non-issue
:Distributed Coordination/Network
elasticmachine
added
the
Team:Distributed (Obsolete)
|
Pinging @elastic/es-distributed (Team:Distributed) |
|
closing this one, part of this has been introduced in #91367 |
original-brownbear
removed
>non-issue
:Distributed Coordination/Network
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We can push deserialization off to the handling thread-pool instead of doing it on the transport threads
when forking anyway. In case of very large messages like bulk request that can take on the order of a second
to fully deserialize this prevents clusters from becoming unstable because transport threads become randomly
blocked on this kind of deserialization work.
Also, on balance this change could reduce load from GC because we trade longer lived buffers that are cheap to recycle
for shorter lived concrete deserialized transport messages. On the flip-side of things, for smaller messages the overhead
from keeping buffers for longer (buffer page size > message size) increases memory use in some cases potentially.