Requesting more messages from the Deframer causes unnecessary context-switching

[louiscryan]

In the case of a incoming stream of messages the flow-control window may accommodate more than one message. If the deframer has several messages in its currently held buffer we end up doing a lot of context switching to request more messages out as we end up with a sequence like

deframer.request(1) -> jump to app thread -> onPayload() -> call.request(1) -> jump to event loop -> deframer.request(1)

[louiscryan]

@ejona86

Eric and I chatted about this. There are a couple of options on the table, the simpler more immediate fix is to have the deframer default its pending message count to 1, this would fix the issue for unary calls.

The more through fix which would help streaming calls is to make the deframer somewhat thread-safe so the application thread can request more messages without a thread hop. In this case the application thread running inside the channels serializing executor would allow request(x) to schedule more onPayload calls onto the tail of the channel executor which would then pick them up and run them in the same thread. This would be a very significant win for streaming calls as it would eliminate context-switches in the case where there were lots of messages sitting in the deframer as they fit within the flow-control window

[nmittler]

+1 both fixes sgtm ... @louiscryan are you working on PRs for either/both of these?

[carl-mastrangelo]

There seems to be little interest in making this happen, so I am putting this in unscheduled.

[linking12]

Is any progress about this issue?

[ejona86]

@linking12, no there's not been any progress in large part because users weren't noticing/caring. Have you been impacted by this?

[linking12]

@ejona86 not impacted，I want a solution about context-switching cost. thanks!