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 <bed...@gmail.com> 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 > <sebastien.estie...@gmail.com> 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 <w...@1wt.eu> 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 >>
