Hi Nicholas,
On Wed, Sep 19, 2012 at 02:19:38PM +0000, Nicholas Heath wrote:
> Hi,
> We have been testing the haproxy-1.5-dev12 build, and doing comparisons
> between using haproxy to terminate the SSL, and using stunnel or stud to
> terminate the SSL.
>
> The immediate problem that I have found is that the haproxy
> is single threaded. This limits the maximum bandwidth, which is not so much of
> a concern for us, but more importantly it seems that when a new connection is
> made, there is a 5mS pause in the servicing traffic on ports that are already
> open.
This is precisely why we designed from the beginning with multi-process
in mind. Right now it's not easy yet to do but still doable. The principle
is to dedicate some processes to handle SSL and SSL only, and have the
remaining processing in a separate process.
What you can do would look like this :
global
nbproc 4
listen ssl-front
bind-process 2,3,4
bind :443 ssl crt /etc/haproxy/certs.d
server http 127.0.0.1:81 send-proxy
listen http
bind-process 1
bind :80
bind :81 accept-proxy # receives connexions from ssl-front
mode http
option forwardfor
option http-server-close
server web 192.168.1.1:80 ...
As you can see, haproxy is started with 4 processes, 3 of which are used
to decipher SSL, and the last one to process HTTP. The SSL listeners
forward clear traffic to the other process and pass all src/dst address
information via the PROXY protocol. The last process only handles low
latency processing (HTTP).
Note that this only makes sense on a multi-core machine. If you only
have one core, running in single or multi-process won't change anything
anyway, since the scheduling latency will always be present.
Regards,
Willy
