Details
Description
Client-side streaming works slowly when spam with small messages.
for (uint64_t i = 0; i < mCalls - 1; ++i) {
request.setPing(i);
stream->writeMessage(request);
}
The above code consumes lot of time especially if the mCalls number is huge.
The flame graph tst_bench_qtgrpcclient_dwarf_client_stream.svg shows that we spend lot of time on internal event queue locks. This happens because of frequent calls of the QNonContiguousByteDevice::deleteLater.
It's indeed should be optimized. The current proposal is to use of the different QHttp2Stream::sendDATA signature and control the QNonContiguousByteDevice lifetime from the QGrpcHttp2Channel side, but not leave this to QHttp2Stream internal logic. The re-usability of the QNonContiguousByteDevice* is questionable(most probably we still need to delete it after completing the sendDATA call, but we at least may try to clear its memory directly but not by using the deleteLater.
Attachments
Issue Links
- is required for
-
QTBUG-129161 Various enhancements in Qt gRPC and Protobuf
-
- In Progress
-
For Gerrit Dashboard: QTBUG-126451 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
571447,13 | QGrpcHttp2Channel: optimize client side streaming under high load | dev | qt/qtgrpc | Status: MERGED | +2 | 0 |
575486,3 | QGrpcHttp2Channel: optimize client side streaming under high load | 6.8 | qt/qtgrpc | Status: MERGED | +2 | 0 |