-
Improvement
-
Resolution: Done
-
Medium
-
None
-
None
AsyncSshHandlerReader attaches to public client-side interface, issuing asynchronous reads. Each such read requires a buffer into which it is going to be fed.
This unfortunate design is a legacy from previous SSH library we used and is not as efficient as we can go.
Specifically, we need to use a relatively small buffer, because we can have a large number of devices – hence 2 are going with 2KiB. This means there are really two levels of queueing going on:
- sshd-internal buffering from socket to internal client queue
- internal queue to our async read
Furthermore we have NETCONF message reassembly sitting on top this queueing, which defaults to at most 16 ByteBufs before coalescence. The interplay of these is very unfortunate:
- sshd reads in 32KiB chunks (based on
NETCONF-571) - this is then fragmented to 16x2KiB to fit into async reads
- this is then reassembled to a 32KiB bytebuf
This results in aweful lot of copying for NETCONF message larger than 32KiB, with the hurt being exponential with the size of messages.
- blocks
-
NETCONF-571 Rework SSHD integration
- Resolved
- relates to
-
NETCONF-686 CSIT regression in netconf-csit-1node-scale-only-sodium
- Verified
- split to
-
NETCONF-699 Eliminate use of AsyncSshHandlerReader in call home
- Resolved