-
Bug
-
Resolution: Done
-
Major
-
None
-
None
-
None
Our current Netty service handlers all call flush once the operation is completed. This works fine, however if a pipeline of commands are sent on the socket, this can cause a big latency issue as each command is individually flushed. If we add the FlushConsolidationHandler, instead the commands will be flushed when one of the following three things happen
1. The socket buffer has been fully read and readComplete event is fired (this is what happens when a person does a sync get call for example or not enough bytes is written to cause a second command to be parsed)
2. The downstream write buffer has been filled up from a large amount of writes (Default is 16 MB iirc)
3. The threshold of manual flushes has been invoked (256 is the default, configurable)
In testing with RESP endpoint with other improvements this increased performance of pipelined commands by an order of magnitude. It should also help HR commands when users invoke getAsync or putAsync in a row.