[stunnel-users] Potential performance degradation moving from Stunnel 5.06 to 5.32

Tue May 24 13:28:17 CEST 2016

There might be a throughput degradation in the more recent versions of
stunnel. I have recently been testing the 5.32 version of stunnel and
have noticed that the tps drop quite significantly when moving from
5.06 to 5.32. Im willing to admit it could be something to do with my
config or testing. But if anyone could offer some suggestions it would
be much appreciated.

The config is setup as follows -
Stunnel VIP -> Haproxy. (I have configured haproxy to return a simple
page). I am using a self signed 1024 bit certificate and the cipher I
am using is ECDHE-RSA-AES256-GCM-SHA384 (I also tested with
aNull:eNULL:MD5:LOW:HIGH and noticed a similar drop in performance)

My Stunnel config is -

setuid = stunnel
pid = /var/run/stunnel/stunnel.pid
debug = local1.0
socket = a:IP_FREEBIND=yes
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1

[VIP_Name-1]
cert = /root/server1024.pem
ciphers = ECDHE-RSA-AES256-GCM-SHA384
accept = 192.168.80.131:443
connect = 127.0.0.1:80
connect = 127.0.0.2:80
delay = no
options = CIPHER_SERVER_PREFERENCE
options = DONT_INSERT_EMPTY_FRAGMENTS
renegotiation = no
TIMEOUTclose = 0

My HAProxy config is -
global
daemon
stats socket /var/run/haproxy.stat mode 600 level admin
pidfile /var/run/haproxy.pid
maxconn 100000
tune.maxrewrite 1024
nbproc 3

defaults
#mode http
#balance roundrobin
timeout connect 4000
timeout client 42000
timeout server 43000

peers loadbalancer_replication
peer lbmaster localhost:7778
peer lbslave localhost:7778

listen VIP_Name
bind 127.0.0.1:80 transparent
#bind 192.168.80.121:80 transparent
monitor-uri /
mode http
errorfile 200 /etc/haproxy/200.http

listen VIP_Name_2
monitor-uri /
mode http
bind 127.0.0.2:80 transparent
errorfile 200 /etc/haproxy/200.http

All the versions of stunnel mentioned here have been built against
Openssl1.0.1s

I am using siege to generate the load and issuing the following command -
siege https://192.168.80.131 -t1M -c 15 -b

The test is stop stunnel service, replace stunnel binary with
different version, restart service, run test.

The results im seeing are as follows (All results are quoted in
transactions per second as reported by siege).
v5.06 - 2233
v5.07 - 2229
v5.25 - 2171
v5.30 - 2092
v5.32 - 302

In my results you can see roughly a 200 tps drop from version 5.06 to
v5.30 then when we get to v5.32 it drops further. To reiterate the
only thing I am changing in my configuration is the stunnel binary.
Everything else is remaining the same.

Does anyone have any ideas what could be happening?

Thankyou

Mark