On 11/13/2014 9:36 AM, Lukas Tribus wrote: >> I started out with haproxy 1.5.8 from source on CentOS 5. It quickly >> became apparent that this system would not accommodate any of the cool >> technologies that Ilya talked about. > > I don't follow, can you elaborate? I didn't watch the video, but Ilya's record > size optimizations are in fact in 1.5 [1].
The openssl in CentOS 5 is ancient - 0.9.8e - so configuring the cool things Ilya mentioned in haproxy didn't work because the underlying SSL wasn't capable. That ancient software did have one bonus for us -- we were not affected by heartbleed. > Currently HAProxy doesn't support SPDY nor HTTP2. You can however configure > NPN/ALPN accordingly and forward such content to a SPDY/HTTP2 capable backend, > if that what you would like todo. > > Once HTTP2 is fully implemented, this will no longer be necessary. > >> What's the timeframe for HTTP2 support in haproxy? > > I don't think there is an ETA for this, but I may be wrong. You most certainly > don't want to hold your breath until it is supported though. I read the draft HTTP 2.0 RFC a few weeks ago. I'm very excited to see the improvements that it promises. Implementing the spec is not going to be easy, so I'm not surprised that the support is not coming right away. I guess I'd just like to know if we could expect it next year, or if it might take longer. >> I'm seeing fairly long "time to first byte", even with the new software >> stack. > > I suspect you will have to analyze what actually happens on the wire with > a sniffer. TLS inefficiencies are not the only reason for high TTFB's. I actually suspect most of that time due to our own code running in Liferay/Tomcat, but I'd like to be able to say that I've done everything I can to eliminate TCP, HTTP, and SSL as bottlenecks. If haproxy with a recent openssl will automatically do dynamic record sizes without config, then I need to know that, or else I need the config required to turn it on. I did look in the documentation and came up empty. >> The openssl version I'm using is 1.0.1f-1ubuntu2.7 ... which apparently >> does not support ALPN. What is the minimum version required for ALPN? > > ALPN is in OpenSSL 1.0.2. You can build from current 1.0.2 branches > if ALPN is a strong requirement. But be aware that a "apt-get upgrade" > will not update your setup when all hell breaks loose because of another > OpenSSL vulnerability. > >> What would the procedure be if I want to compile another version of >> openssl or boringssl in addition to the packaged version, and then use >> it to compile haproxy? > > Check README, I added some instructions to statically link against openssl > some time ago. > > You probably want to avoid boringssl aslong as you don't want to dive > really deep into this crypto stuff. Boringssl as-is isn't really optimized > for production, doesn't have OCSP stapling and only works with HAProxy 1.6. > > If you want get all alternative, I suggest to use latest LibreSSL, which is > production ready and has some pretty nice improvements. It also works > fine in HAProxy stable. I'd like to keep the ubuntu packaged openssl for any packaged software, and install an additional library (doesn't have to be an alternate implementation, I'd be OK with newer openssl) that I'll use when compiling haproxy. I'm only pursuing ALPN because everything says that it replaces NPN ... I don't think that would happen if it weren't better in some way. If upgrading haproxy's openssl and switching to ALPN won't achieve performance differences above single-digit milliseconds, then I can abandon this path. >> In order to ensure the links are correct, I also use SSL on the >> backends, and I force RC4-MD5 so that is efficient as possible. > > Do you mean that the only reason for using SSL to connect to your > backends is that the backend knows that the client connected in https? > Then you are doing it for the wrong reason. > You can use some specific headers to signal your backend that the > frontent session is https [4], without actually encrypting the backend > traffic. > > SSL Handshake on the backend side will kill performance if not > very carefully optimized (keep-alive and SSL session caching). I'd love to switch to non-SSL for the back end ... but I don't know what headers to include to convince the back end to construct https links. If you know of an accurate guide for Tomcat and Liferay/Tomcat, please give me any info you have. Right now the connection goes to Apache (a really old version) and Apache relays it to Tomcat via ajp, but if I could cut out that middleman, performance would likely go up. I'm fairly sure that haproxy does keepalive (I haven't disabled it), and I believe we have enabled keepalive on the back end, but I am not positive. I would expect the latency on the Internet side of the equation would dwarf any overhead from opening multiple connections on the backend LAN, though. Thanks, Shawn
