[sftp] bump pending request count from 1 to 128

Authored by sitter on Sep 12 2018, 2:58 PM.


[sftp] bump pending request count from 1 to 128

with the previous value we basically did sync reading which means that
network and cyrptographic overhead head a huge impact on throughput.
meanwhile the perfect way to use asyncness is to schedule a whole bunch of
requests before starting to read.
previously this was documented as auto-adjusting, which it never was,
there's also little to be gained from adjusting this value on the fly.
more requests in most scenarios will simply mean a larger RAM footprint as
more data potentially sits in libssh waiting to be read. with 128 requests
that'd be ~8mb (assuming the file transferred is that large)

this improves read performance with libssh 0.8 by up to 20 times for large
files. read performance with libssh 0.6 is 2 to 3 times better.
the faster the connection the higher the gain of course.

128 gives somewhat competitive performance results compared to openssh's
ssh implementations while not having too large a footprint.

in raw numbers: a local link read was averaging around 10mb/s on both
libssh versions. with 128 requests this goes up to 200. competitive is
between 200 and 300 it seems (obviously all specific to my system)

CHANGELOG: sftp file reading is now up to 20 times faster

Reviewers: broulik

Reviewed By: broulik

Differential Revision: https://phabricator.kde.org/D15452


sitterSep 18 2018, 1:16 PM
Differential Revision
D15452: [sftp] bump pending request count from 1 to 128
R320:bc22cb54419a: [sftp] use UDSEntry::fastInsert instead of deprecated insert