Subject: Re: Pipelining and recent sftp upload improvements

Re: Pipelining and recent sftp upload improvements

From: Daniel Stenberg <>
Date: Fri, 3 Dec 2010 13:51:46 +0100 (CET)

On Mon, 29 Nov 2010, Will Cosgrove wrote:

> The advantages of this is that you can call write_async_begin say, 10 times
> in a row, then starting draining the acks using write_async, this minimizes
> network latency (aka sitting on a select() call) and does a better job
> maxing out available bandwidth.

Advantage compared to the original naive implemention yes, but not to the
current SFTP upload code, right?

> The advantages of this method to the new write pipelining on the 1.2.8
> branch is that you don't have to pre-read a large buffer of data into
> memory.

How come? If you want to send a lot of data, you need it there. I don't see
how your API makes it use any less data in memory if you want to achieve the
same amount of pipelining. Similarly, your way and my way both get less
pipelining if you use less buffer memory. A fair trade-off methinks.

> The disadvantage is it's more leg-work for the implementor because you have
> to track the offsets and drain replies manually.

I actually only see disadvantages with this quirky API as I believe we can
reach the same model of sending without forcing this onto our users.

> Thinking out loud, it might be worth adding a convenance API that takes a
> file path and does all this 'behind-the-scences' like the openssh
> do_upload/do_download methods do.

Why? What is so bad with my current approach? It certainly maintains a very
simple and familiar API to users (not to mention unmodified) and yet it should
be possible to reach at least roughly the same throughput.

> Now for the ever-so-important speed improvements. I'm testing against an
> internal server (RAID'ed) on a gigabit ethernet. My before benchmarks were
> about 12 MB/sec upload using 1.2.7 stable release. My after is about 53
> MB/sec upload. When shelling out to openssh's sftp, I can get about 73
> MB/sec. Ideally I'd like to get libssh up to ssh's performance levels, but
> that's for another day.

That sounds cool, but isn't that a low-latency connection?

Received on 2010-12-03