Peter wrote:
> 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.
OK. Hopefully I'll have time to do that.
> 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'll get Wireshark captures of the WAN uploads.
Unfortunately, that will have to wait at least until tonight (US time),
because at home is the only place I have an Internet connection that
isn't being used sporadically by many other people.
I didn't have a Linux environment readily at hand at home last night.
I'll have to put one together.
> 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.
The data came from the local filesystem.
I did not report the results of the first upload, which sometimes
was slightly slower than subsequent uploads.
I have plenty of RAM in my systems, and I think the various
OSes do a very good job of caching recently-used files when they
are much smaller than the amount of available memory.
The results were quite reproducible after the first run, so I
don't think we need to worry about filesystem slowness as an issue here.
Regards,
Mark
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2010-11-18