Re: ssl offloading

2016-03-31 Thread Nathan Williams
stunnel's what we used before Haproxy had it built in, which worked fine, but SSL offloading in Haproxy's been excellent in our experience, so my guess would be that you could make it work with some config tuning. On Thu, Mar 31, 2016, 12:45 PM Lukas Tribus wrote: > > Hi

RE: ssl offloading

2016-03-31 Thread Lukas Tribus
> Hi list, > > what are your ideas about offloading of ssl? ssl inside haproxy is nice > but is very expensive. Why would you think that? Lukas

Re: send-proxy behavior when the client closes the connection prematurely

2016-03-31 Thread Frederik Deweerdt
On Tue, Mar 29, 2016 at 11:24 PM, Willy Tarreau wrote: > Hi Frederik, > > On Mon, Mar 28, 2016 at 02:31:27PM -0700, Frederik Deweerdt wrote: >> Hi, >> >> I've been working on an issue we've been seeing on very high loads with >> a configuration that boils down to: >> >> [SSL

ssl offloading

2016-03-31 Thread Gerd Mueller
Hi list, what are your ideas about offloading of ssl? ssl inside haproxy is nice but is very expensive. So I would like to offload the ssl to something else.  Any ideas? Thanks, Gerd

Re: Question about Keep-Alive behaviour

2016-03-31 Thread Craig McLure
Hi Baptiste, Thanks for the answer, it does help! There have been discussions on the list about maintaining a connection pool with backend servers for the purposes of keep-alive, are there any plans for this in the near future? If not, can you recommend a way to handle such behaviour outside of

Re: redirect returning empty response.

2016-03-31 Thread Colin Leavett-Brown
Hello Shawn & Willy, Thank you both for responding. I was trying to work around a problem I am having terminating an ssl/tls connection. Neither apache nor haproxy would handle the request as I expected. It appears that there may be a problem with the certificates. I will keep you posted.

Re: Increased CPU usage after upgrading 1.5.15 to 1.5.16

2016-03-31 Thread Janusz Dziemidowicz
2016-03-31 12:21 GMT+02:00 Lukas Tribus : > Pretty sure, I killed one process after another in between the tests. > > I also compiled with USE_PRIVATE_CACHE=1 to disable inter process > session ID caching, and I can see that session caching definitely > fails (which is

RE: Increased CPU usage after upgrading 1.5.15 to 1.5.16

2016-03-31 Thread Lukas Tribus
> I am well aware that broken resumption is a bad thing. However, I've > looked though haproxy 1.5 code and I quite don't understand how > tickets are supposed to work with nbproc>1. The only code related to > TLS tickets in 1.5 is the code to disable them. Otherwise OpenSSL > defaults are used,

Re: Add servers without disruption

2016-03-31 Thread Cyril Bonté
Hi all, Le 31/03/2016 07:23, Baptiste a écrit : On Thu, Mar 31, 2016 at 7:00 AM, Paul Draper wrote: it's already doable in 1.6 Great. (It seems that the stats socket commands disappeared from the HTML docs in 1.6.) It has been moved into a doc/management.txt which

map_dom vs map_str

2016-03-31 Thread Gerd Mueller
Hi all, just read in the documentation that map_str uses a balanced tree vs. map_dom is using a list. So why should I use map_dom? Right now I am using following: use_backend %[req.hdr(host),lower,map_dom(/etc/haproxy/hostname2backend.map,default _backend)]  Would map_str improve the

Re: Increased CPU usage after upgrading 1.5.15 to 1.5.16

2016-03-31 Thread Janusz Dziemidowicz
2016-03-30 21:22 GMT+02:00 Lukas Tribus : > Hi Janusz, > >> So there is no difference. Session ID based resumption works ok, >> ticket based resumption is kinda broken in both versions. Are tickets >> supposed to work properly with nbproc>1? > > I just tested it here, ticket