[PATCH] Improving sftp client performance

[Tobias Ringström]

On Fri, 4 Jan 2002 mouring at etoh.eviladmin.org wrote:

> No it was not in the CVS tree yet.  There was still discussions as to the
> implementation.  I have a version that does not do more more then two
> overlapping writes.

I tried to vary the number of overlapping writes, but there is something 
(not so) funny going on that I must understand first.  It seems to have 
something to do with pipes/lo in Linux.  I'll be back...

> I'll have to take a look at your patch a little closer, but I worry about
> attempting to optimize the number of writes/reads done in a single
> sitting.  This could feesable change per hardware, per network, etc.  If

But more should be better unless we hit errors or EOF.  That must be 
balanced of course.  I really think that the gain from one to two should 
be really big, and that it should not increase much after that.  I do not 
yet understand why this does not seem to be the case.

> we want to go this way I really suggest we flesh out that defination using
> -r.  That way the user can optimize it for themselves.  With -r 1 mimicing
> the current behavior.  Then set a default (2 - 4) if -r is not used.

That is certainly doable.  The patch I sent was just to get some more 
feedback.  I'd like to try a couple of things more before I'm satisfied.  
And as I said above, I seem to have hit some be interaction with pipes and 
localdevs in Linux.

Btw, you need to handle reordered responses in your patch to be draft
standard compliant.  Just check for an interval of id:s when reading the
status message.

/Tobias