Enhancement/performance optimizations - phase 2

[puzpuzpuz]

Includes the following:

• Major performance optimization - automated pipelining. Includes related config settings.
• Major performance optimization - socket reads optimization.
• A bunch of micro optimizations aimed to get rid of unnecessary buffer allocation and copying, reduce amount of litter produced on the hot path and improve performance/memory consumption, in general.
• Ref doc section for automated pipelining.
• Disables Nagle's algorithm for TCP socket by the default. Includes related config settings.
• Additional unit and integration tests that cover new behavior.

Automated pipelining

The idea is based on the write queue implemented in DataStax Node.js Driver for Apache Cassandra (thanks @tkountis for finding this optimization and implementing the initial PoC). This optimization provides a significant throughput improvement (+25-30%) for in read scenarios. However, throughput slightly decreases in write scenarios (-13-23%). But in the real world scenarios (mixed, with more reads than writes) the benefit should be still significant.

The main benefit of this approach when compared with dedicated pipeline/batch operation APIs is the no explicit APIs for client users. Library users don't need to change their application logic (and thus, the source code) in order to benefit from automated pipelining. Whenever operations are started within the same event loop phase, PipelinedWriter object will try to send their payloads in a batch.

Current value of threshold for PipelinedWriter is set to 8KB (like in DataStax's write queue). I've tried higher values, but saw no difference, so I ended up with the same default.

There is one important underwater stone related with PipelinedWriter's behavior. As it concatenates buffers for multiple operations and flushes them in a single socket.write() call, the underlying runtime (network stack/kernel/OS) may send first parts of the payload over the network earlier than next parts. So, payloads of first operations within the batch may be send over the network before the socket.write()'s callback is executed. As the result, response for that operation may return into socket.on('data') earlier than promise resolve() calls for last operations in the batch. But in case of Hazelcast Node.js client library this behavior is acceptable: operation's write promise (the one that is send into PipelinedWriter#write method) is used only to chain an error handler (see InvocationService#invoke*).

Socket reads optimization

This one removes buffer allocation and copying where possible in socket.on('data') event handling, including the case when the payload is received withing 2+ chunks (note: by default Node uses 64KB for TCP read chunk size). In that case, FrameReader object caches chunks in an internal array and concatenates them only when enough data was received.

Benchmarks

You may see benchmarks results for one of intermediate commits within this PR here. I'm going to perform measurements for the latest commit later.

Further Optimizations

A couple of PRDs were created as the result of work on this PR:

• https://hazelcast.atlassian.net/wiki/spaces/PM/pages/1749254626
• https://hazelcast.atlassian.net/wiki/spaces/PM/pages/1753219150

[puzpuzpuz]

verify

[puzpuzpuz]

verify

[tkountis]

LGTM
Good work!

[mdumandag]

Added a few minor comments. Looks good

[mdumandag]

verify