Re: Proxy Protocol in 1.4.x ?
I wish I have enough time :) All the bench have been run, just need time to write it down! cheers On Tue, Aug 23, 2011 at 2:04 PM, Sebastien Estienne wrote: > could publish some benchmark of haproxy + all best ssl frontend. > i think it would be really valuable infos for the haproxy community. > thanx > > -- > Sebastien E. > > > Le 23 août 2011 à 13:29, Baptiste a écrit : > >> Hi Sebastien, >> >> Actually, bumptech has not yet integrated all the patches developed by >> Emeric. >> And the stunnel version used is the one without Exceliance (Emeric >> again) patches. >> >> But definitely, stud is interesting. >> >> cheers >> >> >> On Tue, Aug 23, 2011 at 1:02 PM, Sebastien Estienne >> wrote: >>> New benchmark on this topic with haproxy: >>> http://vincent.bernat.im/en/blog/2011-ssl-benchmark.html >>> >>> >>> On Saturday, July 9, 2011, Willy Tarreau wrote: Hello Sébastien, On Fri, Jul 08, 2011 at 11:17:12PM +0200, Sébastien Estienne wrote: > yes we perfectly understand this, and that is what we like about haproxy. > But the demand for SSL is growing, it s even mandatory for some use > cases. > Stud looks really promising and solid and a good match for haproxy as it > was designed to be used with haproxy ( > http://devblog.bu.mp/introducing-stud > ). > Today we have the choice between: > - haproxy 1.4 + patched stunnel > - haproxy 1.5 dev + stud > - patched haproxy 1.4 + stud > > The last one seems the most stable with the best performance, so as the > demand for SSL is growing, i think it would be a big plus that haproxy 1.4 > can work with stud without being patched. I see your point. Well, there is also a fourth solution. At Exceliance, we have an "haproxy enterprise edition (hapee)" packaging which includes a patched haproxy 1.4, patched stunnel etc... There's a free version you can register for. We decided to install it as some of our supported customers for free, just because it made maintenance easier for us, and rendered their infrastructure more stable. > I don t know if it would make sense but maybe stud could be integrated > somehow in haproxy like this: > Instead of starting stud then haproxy separately, the main haproxy > process could fork some stud-like process (binding 443) as it already > forks > haproxy childs for multicore and it would discuss using the proxy protocol > transparentlyfor the end user with no need to setup the link between both. It's amusing that you're saying that : when I looked at the code, I thought "they use the same design model as haproxy and they have the same goals, maybe this could be merged". My goal with SSL in haproxy is that we can dedicate threads or processes to that task, thus some core changes are still needed, but a first step might precisely be to have totally independant processes communicating over a unix socket pair and the proxy protocol. It's just not trivial yet to reach the server in SSL, but one thing at a time... > This would offer a seemless SSL integration without hurting haproxy > codebase and stability for clear http content. Exactly. Thanks for your insights, they comfort me in that mine were not too excentric :-) Willy >>> >>> -- >>> Sebastien Estienne >>> >
Re: Website crawling while connecting via haproxy balanced url
Hi Willy, Thanks as always for the great support and suggestions but this morning the user called me and said that his ISP fixed the issue being "Something in Network Operations" so now the connections are fine, but will surely keep your feedback handy for future issues From: Willy Tarreau To: Amol Cc: "haproxy@formilux.org" Sent: Tuesday, August 23, 2011 2:12 AM Subject: Re: Website crawling while connecting via haproxy balanced url Hi Amol, On Mon, Aug 22, 2011 at 09:01:31AM -0700, Amol wrote: > Hi, > One of my tester complained this morning that he can access the servers fine > when he hits them individually and with decent response time, but when he > access via the haproxy load balanced url, the website is crawling for him. > The other interesting thing is people at other locations have no issues at > all. > > So can you please tell me how can i debug this very specific issue with this > connection, > > what we have tried so far is > > restart is mac > restart his home router > reset safari > reset firefox > > But the issue still persists? Well, at least the haproxy configuration would help, and ideally you should take tcpdump traces on the haproxy machine for this IP address. That way you'd be able to : 1) say whether or not what he sees is normal 2) determine if the issue is client-side or haproxy-side 3) find a workaround or a fix 4) sometimes discover a bug somewhere :-) Regards, Willy
Re: Proxy Protocol in 1.4.x ?
could publish some benchmark of haproxy + all best ssl frontend. i think it would be really valuable infos for the haproxy community. thanx -- Sebastien E. Le 23 août 2011 à 13:29, Baptiste a écrit : > Hi Sebastien, > > Actually, bumptech has not yet integrated all the patches developed by Emeric. > And the stunnel version used is the one without Exceliance (Emeric > again) patches. > > But definitely, stud is interesting. > > cheers > > > On Tue, Aug 23, 2011 at 1:02 PM, Sebastien Estienne > wrote: >> New benchmark on this topic with haproxy: >> http://vincent.bernat.im/en/blog/2011-ssl-benchmark.html >> >> >> On Saturday, July 9, 2011, Willy Tarreau wrote: >>> Hello Sébastien, >>> >>> On Fri, Jul 08, 2011 at 11:17:12PM +0200, Sébastien Estienne wrote: yes we perfectly understand this, and that is what we like about haproxy. But the demand for SSL is growing, it s even mandatory for some use cases. Stud looks really promising and solid and a good match for haproxy as it was designed to be used with haproxy ( http://devblog.bu.mp/introducing-stud ). Today we have the choice between: - haproxy 1.4 + patched stunnel - haproxy 1.5 dev + stud - patched haproxy 1.4 + stud The last one seems the most stable with the best performance, so as the demand for SSL is growing, i think it would be a big plus that haproxy 1.4 can work with stud without being patched. >>> >>> I see your point. Well, there is also a fourth solution. At Exceliance, we >>> have an "haproxy enterprise edition (hapee)" packaging which includes a >>> patched haproxy 1.4, patched stunnel etc... There's a free version you can >>> register for. We decided to install it as some of our supported customers >>> for free, just because it made maintenance easier for us, and rendered >>> their infrastructure more stable. >>> I don t know if it would make sense but maybe stud could be integrated somehow in haproxy like this: Instead of starting stud then haproxy separately, the main haproxy process could fork some stud-like process (binding 443) as it already forks haproxy childs for multicore and it would discuss using the proxy protocol transparentlyfor the end user with no need to setup the link between both. >>> >>> It's amusing that you're saying that : when I looked at the code, I >>> thought >>> "they use the same design model as haproxy and they have the same goals, >>> maybe this could be merged". My goal with SSL in haproxy is that we can >>> dedicate threads or processes to that task, thus some core changes are >>> still >>> needed, but a first step might precisely be to have totally independant >>> processes communicating over a unix socket pair and the proxy protocol. >>> It's just not trivial yet to reach the server in SSL, but one thing at a >>> time... >>> This would offer a seemless SSL integration without hurting haproxy codebase and stability for clear http content. >>> >>> Exactly. >>> >>> Thanks for your insights, they comfort me in that mine were not too >>> excentric :-) >>> >>> Willy >>> >>> >> >> -- >> Sebastien Estienne >>
Re: Proxy Protocol in 1.4.x ?
Hi Sebastien, Actually, bumptech has not yet integrated all the patches developed by Emeric. And the stunnel version used is the one without Exceliance (Emeric again) patches. But definitely, stud is interesting. cheers On Tue, Aug 23, 2011 at 1:02 PM, Sebastien Estienne wrote: > New benchmark on this topic with haproxy: > http://vincent.bernat.im/en/blog/2011-ssl-benchmark.html > > > On Saturday, July 9, 2011, Willy Tarreau wrote: >> Hello Sébastien, >> >> On Fri, Jul 08, 2011 at 11:17:12PM +0200, Sébastien Estienne wrote: >>> yes we perfectly understand this, and that is what we like about haproxy. >>> But the demand for SSL is growing, it s even mandatory for some use >>> cases. >>> Stud looks really promising and solid and a good match for haproxy as it >>> was designed to be used with haproxy ( http://devblog.bu.mp/introducing-stud >>> ). >>> Today we have the choice between: >>> - haproxy 1.4 + patched stunnel >>> - haproxy 1.5 dev + stud >>> - patched haproxy 1.4 + stud >>> >>> The last one seems the most stable with the best performance, so as the >>> demand for SSL is growing, i think it would be a big plus that haproxy 1.4 >>> can work with stud without being patched. >> >> I see your point. Well, there is also a fourth solution. At Exceliance, we >> have an "haproxy enterprise edition (hapee)" packaging which includes a >> patched haproxy 1.4, patched stunnel etc... There's a free version you can >> register for. We decided to install it as some of our supported customers >> for free, just because it made maintenance easier for us, and rendered >> their infrastructure more stable. >> >>> I don t know if it would make sense but maybe stud could be integrated >>> somehow in haproxy like this: >>> Instead of starting stud then haproxy separately, the main haproxy >>> process could fork some stud-like process (binding 443) as it already forks >>> haproxy childs for multicore and it would discuss using the proxy protocol >>> transparentlyfor the end user with no need to setup the link between both. >> >> It's amusing that you're saying that : when I looked at the code, I >> thought >> "they use the same design model as haproxy and they have the same goals, >> maybe this could be merged". My goal with SSL in haproxy is that we can >> dedicate threads or processes to that task, thus some core changes are >> still >> needed, but a first step might precisely be to have totally independant >> processes communicating over a unix socket pair and the proxy protocol. >> It's just not trivial yet to reach the server in SSL, but one thing at a >> time... >> >>> This would offer a seemless SSL integration without hurting haproxy >>> codebase and stability for clear http content. >> >> Exactly. >> >> Thanks for your insights, they comfort me in that mine were not too >> excentric :-) >> >> Willy >> >> > > -- > Sebastien Estienne >
Re: Proxy Protocol in 1.4.x ?
New benchmark on this topic with haproxy: http://vincent.bernat.im/en/blog/2011-ssl-benchmark.html On Saturday, July 9, 2011, Willy Tarreau wrote: > Hello Sébastien, > > On Fri, Jul 08, 2011 at 11:17:12PM +0200, Sébastien Estienne wrote: >> yes we perfectly understand this, and that is what we like about haproxy. >> But the demand for SSL is growing, it s even mandatory for some use cases. >> Stud looks really promising and solid and a good match for haproxy as it was designed to be used with haproxy ( http://devblog.bu.mp/introducing-stud). >> Today we have the choice between: >> - haproxy 1.4 + patched stunnel >> - haproxy 1.5 dev + stud >> - patched haproxy 1.4 + stud >> >> The last one seems the most stable with the best performance, so as the demand for SSL is growing, i think it would be a big plus that haproxy 1.4 can work with stud without being patched. > > I see your point. Well, there is also a fourth solution. At Exceliance, we > have an "haproxy enterprise edition (hapee)" packaging which includes a > patched haproxy 1.4, patched stunnel etc... There's a free version you can > register for. We decided to install it as some of our supported customers > for free, just because it made maintenance easier for us, and rendered > their infrastructure more stable. > >> I don t know if it would make sense but maybe stud could be integrated somehow in haproxy like this: >> Instead of starting stud then haproxy separately, the main haproxy process could fork some stud-like process (binding 443) as it already forks haproxy childs for multicore and it would discuss using the proxy protocol transparentlyfor the end user with no need to setup the link between both. > > It's amusing that you're saying that : when I looked at the code, I thought > "they use the same design model as haproxy and they have the same goals, > maybe this could be merged". My goal with SSL in haproxy is that we can > dedicate threads or processes to that task, thus some core changes are still > needed, but a first step might precisely be to have totally independant > processes communicating over a unix socket pair and the proxy protocol. > It's just not trivial yet to reach the server in SSL, but one thing at a > time... > >> This would offer a seemless SSL integration without hurting haproxy codebase and stability for clear http content. > > Exactly. > > Thanks for your insights, they comfort me in that mine were not too > excentric :-) > > Willy > > -- Sebastien Estienne
