On Wed, Jun 11, 2025 at 01:32:33PM +0100, Edwin Torok via stunnel-users wrote:
On Tue, Jun 10, 2025 at 10:21 PM Michał Trojnara via stunnel-users [email protected] wrote:
Hi Guys,
For the stunnel project, my priorities are:
- Security
- Reliability
- Scalability
- Performance
[snip]
There are two primary sources of performance bottlenecks:
- Connection rate – The number of new connections established per
second. Establishing a new connection involves asymmetric cryptography, which is computationally expensive and therefore typically the main performance bottleneck. 2. Connection throughput – The data rate of a single connection, which—at least in user space—is handled by a single CPU thread. This is almost always faster than the network interface’s throughput and thus rarely a limiting factor.
Hi,
Thank you for the quick response, and for stating the goals so clearly. I think my use-case fits within 'Performance bottlenecks on connection throughput on high-end servers':
The reason I started looking into stunnel performance is because it is using 96-100% CPU and is a bottleneck for the application I'm working on, even on relatively slower (by today's standards) 10Gbit/s networks.
[snip]
The current OpenSSL performance settings were selected because they have been extensively tested by numerous users across many OpenSSL versions and network stacks. Any change would require a compelling reason.
The use case is live migrating VMs, where the connection between 2 hosts is encrypted using stunnel. Connection rate isn't very important for this use case, but the connection throughput is. In some cases there might be a tradeoff between the two (e.g. memory usage vs performance), it'd be nice to have .conf flags to choose between the two. Although I think when stunnel runs in *client* mode throughput would probably be more important than using a little bit more memory.
Hi,
Apologies to the list members and maintainers if this is considered off-topic and would have been better as a private e-mail. I think it may have some merit as part of the public discussion.
I know that later on you said that you saw no reason currently to migrate away from what you already have setup - i.e. stunnel - and I completely understand that; anything new has to go through rigorous reviews, validations, performance tests, etc. still, are you aware of and have you considered https://www.tarsnap.com/spiped.html - the spipe/spiped client/server suite? It lacks a lot of stunnel's capabilities, but it just might possibly make up for that in performance, which might suit your particular use case.
G'luck, Peter