I would suggest terminating SSL on the haproxy box (with stud in front of it), thus switching haproxy from tcp to http mode. That way, longrunning keepalive-enabled HTTPS sessions terminate there and apache only sees real non-SSL request without blocking any threads. If you would like to avoid terminating SSL on the proxy, you could enable a haproxy+stud on the apache box (apache listens on 80/8080, and stud with haproxy listens on 443). This way, you can still use a dedicated tcp reverse proxy withouth ssl encryption, doing all the ssl work in the backend and you avoid blocking apache threads because you have an event based proxy in front of it (even if it is on the same box).
________________________________ > Date: Wed, 11 Jul 2012 07:15:19 +0530 > Subject: Help with Chrome preconnects > From: [email protected] > To: [email protected] > > hi, > > I am using HAProxy 1.4.x infront of Apache 2.2.x. For SSLs, I just do a > tcp redirect from port 443. Like > == > listen ssl-relay 0.0.0.0:443<http://0.0.0.0:443> > mode tcp > balance roundrobin > server inst1 machinename:443 check inter 2000 fall 3 > == > > Everything was running fine till Chrome introduced preconnects. I have > logged a bug > at http://code.google.com/p/chromium/issues/detail?id=87121 > Its a fairly long thread but the gist is the following : > Chrome does some speculative SSL connects to the backend and does not > close the handshake. The problem for us now is that the request goes to > an Apache process and that process gets blocked for the entire duration > of the timeout! If in httpd.conf we have 60seconds as timeout, there > are one or two Apache processes that will get blocked in "Reading > request" state for 60seconds thinking that the chrome user will use the > connection! As you can easily see, this is really a drain on the > process pool and very soon it maxes out on child processes. > > Is there anyway HAProxy can help here? As in, is there anyway HAProxy > does not open an apache connection till there is any "activity" on the > connection? Please let me know. I guess most systems would have this > problem but for some reason, I can not find enough links on google. > Or if you can think of other ways of handling this, please let me know > that too. > > Thanks, > Vikram
