As you can see, after publishing this article I received some feedback and questions about the comparison, including from the author of stunnel himself, Michal Trojnara. Even though the stunnel website itself states that the default is ‘no compression’, this apparently is not so. It appears iperf’s default data seems to be highly compressible, thus heavily skewing the performance numbers: stunnel was performing very different work than native networking or vCider. To arrive at more realistic numbers, I used a large image transfer (a JPEG) instead, which by its nature is not much more compressible. I transferred this file with iperf (which can use file input) as well as wget, The results? stunnel is much more comparable with both the native and the vCider networking speeds.

Interrupts and context switches are now roughly the same for all three solutions. stunnel still exhibits a significantly higher CPU load (20%), but certainly does not max out the CPU anymore. I suspect that the higher numbers of context switches and interrupts result from iperf’s default behavior of sending as much data as it can in a given time interval. And since stunnel can easily compress iperf’s default data, iperf was able to send a lot of this, which also explains the results reported by iperf.

While I maintain that a setup consisting of multiple nodes is much easier to maintain with vCider – which also provides a number of other interesting features – it must be noted that stunnel does indeed perform very well for point to point connections. Note to self: Be sure not to use synthetic data for performance tests like this.