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 <[email protected]> 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 <[email protected]> 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 >> <[email protected]> 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 <[email protected]> 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 >>> >
