Subject: Re: Updated libssh2 benchmark results

Re: Updated libssh2 benchmark results

From: Peter Stuge <>
Date: Thu, 18 Nov 2010 04:46:30 +0100

Mark Riordan wrote:
> I ran a bunch more performance tests of the latest libssh2,
> and some other SSH clients.
> The results are here:

Quite sad. :(

> The previous results are here:
> As you can see, libssh2 for some crazy reason is much slower
> when uploading to Solaris than it used to be.
> (I tried this many times, and it was repeatable.)

Note that every UNIX system ships with a custom variation of OpenSSH,
so Solaris and Linux are not running the same code on the server.

It would be good to eliminate as many variables as possible, so if
you have access to the Linux and Solaris then maybe you can build the
vanilla OpenSSH portable code and run it as your user on port 2222
for the purpose of testing.

I do not expect it to have even a noticeable impact on test results,
but it helps to have just one reference server, and it also allows
anyone who wants to work on improvement to set up the exact same

> However, I'm more concerned about its mediocre upload performance
> across a WAN.

That's generous. I wouldn't even call that mediocre.

> Presumably the difference there is due to packet delays.

Personally I don't really *know* what the problem is, so to profile
this will require looking a lot at timing and packets, both from
inside the libssh2 app, and from another viewpoint outside the app,
e.g. sniffing packets directly from the OS, or even on the wire.

> I would have thought that Daniel's recent changes would have made
> libssh2 competitive there.

If not competitive, then at least decidedly better.

For these upload tests with libssh2, where did the data come from
that you uploaded? If there is any other I/O in the _sftp_write()
loop then please pre-load all data and remove any swap file, so that
all data is in fact available directly. Again the purpose is not to
significantly improve the numbers, but to create an easily repeatable
environment for further testing and development.

Received on 2010-11-18