SSL backend performance [Was: mod proxy disabling workers after a single error]

[Brian Rectanus <br...@gmail.com>]

On 5/5/07, Ruediger Pluem <rp...@apache.org> wrote:
> On 05.05.2007 04:25, Brian Hayward wrote:
>
>
> > BTW, I did test my patch when 1 host was down in a balancer
> > configuration.  It still seemed to work well.
>
> I would think so. My point was more about that with this setting the
> response times of your reverse proxy will increase as it may try all failed
> workers first before it finds a working one which could be a time consuming
> operation escpecially if you have many failed workers.
>
> > At this time, we lose one or two connections out of thousands.
> > According to the network sniffer for these connections, packets are
> > getting lost during the setup of the connection.  (For example - our
> > sniffer sees a SYN go out, get retransmitted a couple times, but the
> > SYN_ACK never returns for that one connection).  It could have
> > something todo with the HW load balancer, the NAT firewall between us
> > and the destination, remote web servers, or something else.  We're
> > still working on the analysis.
>
> Ouch. These are nasty errors.I wish you good luck in tracking them down.
>
> >
> > As requested, here is the error:
> >
> > [Tue May 01 14:36:30 2007] [error] (145)Connection timed out: proxy:
> > HTTPS: attempt to connect to 1.2.3.4:443 (hostname.com) failed
>
> Just one hint: If you do not have special needs that require
> you to encrypt the connection to your backend you should not do this
> for the following reasons:
>
> 1. Assuming that you are also doing https on the frontend side of your
> reverse proxy doing encryption to the backend means that you need to
> encrypt / decrypt your data twice: Once to the client and once to the
> backend.


Unfortunately this can be required for backends that may be dispersed
around the world.


> 2. Currently you cannot have keepalive connections with mod_proxy to
> a backend. This means that you effectively have *no* connection pooling
> in this case which is bad in general. Even worse: You need to do a full
> and expensive SSL handshake for *every* request to your backend.

A current solution that I am using is to have a local SSL
session-caching proxy on the reverse-proxy machine.  It works well,
but there is a bit of overhead in that as well (although not as much
as a full handshake).

I am curious if there are any plans on adding SSL session caching to
the backend?  Anyone working on it?  If only I had more time ;)

thanks,
-B