search

mwiede / jsch

fork of the popular jsch library
Other
760 stars 144 forks source link

performance of internal jzlib implementation #691

Open mjmst74 opened 4 weeks ago

mjmst74 commented 4 weeks ago

I ran into an issue with JSch 0.2.19, running on OpenJDK 17.0.12 on RHEL 8, where file transfers were taking much longer than expected, with compression set to 6.

For example, I was seeing a 29mb file take 45 seconds to transfer. (This was both with the new JSch 0.2.19 default algorithms, and with the configuration updated to use older algorithms that were defaults in JSch 0.1.55.)

With no compression, a 41mb file took 931 ms to transfer.

Switching to com.jcraft.jsch.juz.Compression, a 43mb file took 683 ms to transfer.

Out of curiousity, I dropped in the jzlib 1.1.3 classes and tried some transfers, and the times were as fast as expected - a 35mb file took 724 ms.

I don't have long-running benchmarks to share, but I did see consistent performance to the examples above over multiple file transfers.

I was wondering if this is expected behavior with the com.jcraft.jsch.jzlib implementation, or if its a possible issue that could be addressed?

norrisjeremy commented 4 weeks ago

I'm not surprised in the least that the JZlib implementation is slower: it is implemented via pure Java, while the java.util.zip implementation is a JNI based wrapper around native Zlib library.

If compression support is important to you and you don't mind that the java.util.zip implementation is not technically compliant to the SSH RFC standards, then you probably will want to use it in preference to the JZlib implementation.

mjmst74 commented 4 weeks ago

Agreed, I'm not surprised that the JZlib implementation is slower - but I was surprised that the JZlib bundled with JSch is so much slower than the old JZlib 1.1.3.

mjmst74 commented 3 weeks ago

I believe I found the issue, PR submitted: https://github.com/mwiede/jsch/pull/692