Throughput degradation after upgrading haproxy from 1.3.22 to 1.4.1

2010-03-12 Thread Erik Gulliksson
Hi! First, I'd like to thank Willy and the other haproxy contributors for bringing this wonderful piece of software into the world :) For the last 2 years now we have been running haproxy 1.3 successfully to load balance our frontend applications and storage services. Mainly the requests passing

Re: Throughput degradation after upgrading haproxy from 1.3.22 to 1.4.1

2010-03-12 Thread Willy Tarreau
Hi Erik, On Fri, Mar 12, 2010 at 11:08:08AM +0100, Erik Gulliksson wrote: > Hi! > > First, I'd like to thank Willy and the other haproxy contributors for > bringing this wonderful piece of software into the world :) Thanks ! > For the last 2 years now we have been running haproxy 1.3 successful

Re: Throughput degradation after upgrading haproxy from 1.3.22 to 1.4.1

2010-03-15 Thread Erik Gulliksson
Hi Willy, Thanks for your elaborative answer. > Did you observe anything special about the CPU usage ? Was it lower > than with 1.3 ? If so, it would indicate some additional delay somewhere. > If it was higher, it could indicate that the Transfer-encoding parser > takes too many cycles but my pr

Re: Throughput degradation after upgrading haproxy from 1.3.22 to 1.4.1

2010-03-15 Thread Willy Tarreau
Hi Erik, On Mon, Mar 15, 2010 at 10:27:38AM +0100, Erik Gulliksson wrote: > Hi Willy, > > Thanks for your elaborative answer. > > > Did you observe anything special about the CPU usage ? Was it lower > > than with 1.3 ? If so, it would indicate some additional delay somewhere. > > If it was high

Re: Throughput degradation after upgrading haproxy from 1.3.22 to 1.4.1

2010-03-18 Thread Erik Gulliksson
Hi, >> > Did you observe anything special about the CPU usage ? Was it lower >> > than with 1.3 ? If so, it would indicate some additional delay somewhere. >> > If it was higher, it could indicate that the Transfer-encoding parser >> > takes too many cycles but my preliminary tests proved it to be

Re: Throughput degradation after upgrading haproxy from 1.3.22 to 1.4.1

2010-03-18 Thread Malte Geierhos
Hello, > > Unfortunately I the "show errors" returned empty, so I guess it > was something else. The good news is that I gave haproxy 1.4.2 a > try today and the 502/PR error with PUT/TE:chunked requests have > now vanished. So thanks for solving this. I'm not sure which one of > the bugs I was hit

Re: Throughput degradation after upgrading haproxy from 1.3.22 to 1.4.1

2010-03-18 Thread Willy Tarreau
Hi Erik, On Thu, Mar 18, 2010 at 02:29:46PM +0100, Erik Gulliksson wrote: > Unfortunately I the "show errors" returned empty, so I guess it was > something else. The good news is that I gave haproxy 1.4.2 a try today > and the 502/PR error with PUT/TE:chunked requests have now vanished. > So thank

Re: Throughput degradation after upgrading haproxy from 1.3.22 to 1.4.1

2010-03-18 Thread Erik Gulliksson
Hi Malte, >> So now when I got a working haproxy 1.4, I continued to try out >> the "option http-server-close" but I hit a problem with our >> stunnel (patched with stunnel-4.22-xforwarded-for.diff) instances. >> It does not support keep-alive, so only the first HTTP request in >> a keepalive-sess

Re: Throughput degradation after upgrading haproxy from 1.3.22 to 1.4.1

2010-03-18 Thread XANi
> So now when I got a working haproxy 1.4, I continued to try out the > "option http-server-close" but I hit a problem with our stunnel > (patched with stunnel-4.22-xforwarded-for.diff) instances. It does not > support keep-alive, so only the first HTTP request in a > keepalive-session gets the X

Re: Throughput degradation after upgrading haproxy from 1.3.22 to 1.4.1

2010-03-18 Thread Erik Gulliksson
Hi Willy On Thu, Mar 18, 2010 at 3:08 PM, Willy Tarreau wrote: > > OK so very likely it's the same problem I fixed yesterday using Bernhard's > captures. Great! Thanks to Bernhard as well then, for providing you with the captures. > yes indeed it's expected. Stunnel is not designed to manipulat

Re: Throughput degradation after upgrading haproxy from 1.3.22 to 1.4.1

2010-03-18 Thread Nicholas Hadaway
I can second this comment and say that it works extremely well... nginx operates very nicely as an SSL offloading device. I am right now using nginx 0.8.33 (soon to bump up to 0.8.34) and HAProxy 1.4.2 in production and things work very well for me. -Nick Maybe it's worth a try for you to

Re: Throughput degradation after upgrading haproxy from 1.3.22 to 1.4.1

2010-03-18 Thread Harvey Yau
I can third this - nginx + haproxy works extremely well. I wish haproxy supported SSL directly. I realize it's not within the design goals of haproxy, but the need for this is out there. Good thing nginx + haproxy works well enough. -- Harvey On 3/18/10 3:29 PM, Nicholas Hadaway wrote: I c

Re: Throughput degradation after upgrading haproxy from 1.3.22 to 1.4.1

2010-03-18 Thread duncan hall
Throw me in a forth on this one. I use nginx 0.8.34 for gzip compression, RAM caching of static content and SSL offload. All very simple to configure and low overheads. All requests HTTP and HTTPs go to Nginx and are then forwarded to HAproxy 1.4.2 as HTTP. Regards, Duncan Harvey Yau wro

Re: Throughput degradation after upgrading haproxy from 1.3.22 to 1.4.1

2010-03-22 Thread Timh Bergström
The problem with nginx is that it doesnt support chunked-encoding. Since that is what we are after, we can't use nginx until it supports it or until we can get rid of chunked encoding. So posting about how good it is working for you is not really helping our issue. Thanks though. BR, Timh 2010/

Re: Throughput degradation after upgrading haproxy from 1.3.22 to 1.4.1

2010-03-22 Thread Nicholas Hadaway
Chunked encoding support... http://github.com/agentzh/chunkin-nginx-module -nick On 3/22/2010 4:57 AM, Timh Bergström wrote: The problem with nginx is that it doesnt support chunked-encoding. Since that is what we are after, we can't use nginx until it supports it or until we can get rid of c

Re: Throughput degradation after upgrading haproxy from 1.3.22 to 1.4.1

2010-03-23 Thread Timh Bergström
Thanks, but we've tested that and it seems like a fugly way of doing things (letting nginx do wrong and rewriting output, seems very inefficient). Also according to the documentation it only supports POST and not PUT without additional hacking. We would love to see a "proper" patch to nginx though