[mtrojnar]

Testing results indicated that stunnel was much faster than the line speed (and thus faster than his own product), but the author simply ignored it. In fact his version of stunnel had DEFLATE/ZLIB compression enabled by default. In order to prove that his own product is better than stunnel, the author of this test decided to compare the bandwith of an uncompressed stream encrypted with his product with the bandwidth of a compressed stream encrypted with stunnel.

[jbrendel]

Well, I contacted you privately to discuss this so that we may both enlighten each other on what's going on, but you did not respond to my email and instead went out publicly. Oh well.

But let's look at it. The physical link was capable of carrying something like 18 Mbit/s. When running iperf through stunnel, it reported more than 400 Mbit/s. But if you look at the actual bandwidth that was used during the transfer, it was indeed just 4.8 Mbit/s.

So, the 400 Mbit/s is clearly an illusion caused by the compression. Compressing a stream is a worth while goal, for sure. And it can be helpful in many cases. But I guess iperf's data is highly compressable. Considering that much of what's transferred these days is already compressed (multi-media files), I doubt that in the real world you will see any sort of speedup even remotely like this.

The fact is this: If it comes to actually transferring data over the wire, stunnel is very slow and there are just no two ways around it. It attempts compression at very high cost in CPU cycles and in the end is still going to be bound by context switches and interrupts.

I'm going to repeat the tests with compression disabled and update the blog post accordingly.

[mtrojnar]

1. It's you who started the flame by publishing your obviously unfair comparison.

2. I didn't receive your email (if you really sent it).

3. Stunnel overrides the OpenSSL default of enabling compression by default since version 4.51 released over a month ago http://www.stunnel.org/?page=sdf_ChangeLog

4. Whether compression is useful or not depends on many factors, including not only type of data, but also available bandwidth and CPU power. And data compression is not an illusion. I'd be afraid to use your products if you don't understand it.

5. Compression is indeed much slower than encryption. This is a fact. Do you really mean that your product is better just because it doesn't support compression?

6. Stunnel is indeed a performance bottleneck, but only if your internet connection is over 0.5Gbps, and your server is as slow as my desktop: http://www.stunnel.org/?page=perf

[jbrendel]

1. Sorry you thought a comparison in which your program doesn't come out on top is a flame. It wasn't. Don't know what's unfair about comparing out of the box, default install performance of two systems.

2. Yes, I sent it, sorry you didn't receive it.

3. I did a standard apt-get install for stunnel on the Ubuntu Oneric system.

4. Sigh. I'm not going to comment on that one.

5. Really don't know where you would get this idea. Also don't understand why you get so upset. As I said, I was more than happy to discuss this with you ahead of time. Let me try to explain this again: I suggested that most real-world data is already compressed, thus the benefits you could derive by doing compression on the wire are lessened to the point where compression won't get you anything. For any compressable data, compressing it before sending is great and beneficial and I never stated otherwise.

[mtrojnar]

Did you really want to discuss your results "ahead of time"? You could easily do it before publishing them. My email address is in the manual of stunnel.

I could argue whether an old Ubuntu package is "out of the box" stunnel, or whether sending 20mbit stream of compressed video is really the most common use of stunnel...