Re: Why SFTP performance sucks, and how to fix it

[Martin Pool <mbp%samba.org@localhost>]

On  8 Jul 2003, Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost> wrote:

> In addition to the protocol-level handbrake, the SFTP protocol that runs on
> top of SSH contains its own handbrake.  This protocol recommends that reads
> and writes consist of no more than 32K of data, even though it's running over
> the reliable SSH transport which is in turn running over the reliable TCP/IP
> transport.  One common implementation limits SFTP packets to 4K bytes,
> resulting in a mere 4% link utilisation in the previously-presented
> scenario.

This reminds me of a problem in rsync: A fundamental protocol design
isssue is whether the recipient of a message should be able to
interrupt it during receipt to indicate an error.  The simplest and
cleanest solution is to require errors be sent after the request is
received, as SFTP does.

If the requests are very large, this causes a problem when, for
example, a destination file cannot be written to because of an
out-of-space error.  A simple server implementation will need to read
in the whole request before it is able to notify the client of the
error.  It is entirely realistic to have a file that takes many
minutes to transfer, and possibly incurs a significant traffic cost.
It is annoying to have all that time or money be wasted when the
server discards the request.

Alternatively the server can drop the connection, or send an
out-of-band error (e.g. over ssh stderr), but both of these introduce
other problems.  Similar issues can be seen to a lesser extent in
HTTP.

I think writing a file as a series of IO chunks is a reasonable and
clean solution but it requires that the length be chosen properly, and
ideally for pipelining to be used.

Of course I agree that 4k or even 32k is too small for most modern
networks.  But I did want to point out that going too far in the
opposite direction can be a problem too.

-- 
Martin