Re: Support for Keep-Alive header and timeouts
Hi, On Mon, Apr 25, 2016 at 3:39 PM, Lukas Tribus <lu...@gmx.net> wrote: > Hi, > > > Am 25.04.2016 um 15:51 schrieb Craig McLure: >> >> >From a firewall perspective all sockets are configured to forcefully >> stop after about 20 minutes after which time a connection will go >> 'stale' and no longer function, any additional packets on that socket >> will be ignored. > > > And why would you configure the firewall to do this? I don't see how this > makes > sense. Resource limitations, physical restrictions, upstream limitations, security requirements, could be anything, it's not really relevant to the discussion, there could be many reasons why someone needed a specific cut-off after a certain amount of time. > > >> This is fine for our purposes, but when keep-alive >> comes into play this raises some problems. Theoretically using all the >> timeouts available in haproxy it's tentatively possible to maintain a >> connection for *LONGER* than that period, at which point the >> connection gets silently dropped, and in haproxy the connection fails >> in a non-graceful way. > > > Even if haproxy would *try* to close the session after time X, there is not > guarantee > that current in flight request/response would be finished in time to not get > dropped > at firewall level. What about slow downloads? They could go on for hours ... This is true if you make assumptions about what's happening on the backend, 10 minutes was (as noted) an example, could be 3 hours, could be 200 years, the relevance here was simply existence of the functionality. As far as connections dropped during in-flight request / response cycle, they should follow the HTTP spec on how to behave in that scenario, and obviously the 'force close' would occur prior to the firewall dropping the connection. > > >> Ideally, obviously, I'd like for haproxy to have a way to close the >> connection as gracefully as possible after X minutes, rather than the >> current scenario where it may get killed ungracefully. > > > This is not supported. This is the answer I needed. > You can simulate this behavior by soft reloading haproxy > every X minutes or by shutting down those "offensive" session via the admin > socket: > > http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#9.2-shutdown%20session > > > However I would strongly suggest you go back to the drawing board and work > out why you need this behavior in the first place. > With that in mind, it's not overly uncommon behaviour. nginx for example has keepalive_timeout to facilitate the behaviour I'm looking for here, I simply needed to know if I had missed something in the manual with regards to haproxys support of this functionality, obviously I hadn't, and as you say it's not supported. > > If you are concerned about the number of open connection on the proxy, just > lower > timeout http-keep-alive to something like 30 - 300 ms. That is way more > effective. > Using a low timeout is the general solution I'm using. Again, the email was sent to see if the drop could be forced, because it's possible even with strict timeouts for a request that a connection could stay for a long time depending on how it's interacting with the backend. > > cheers, > > Lukas > Thanks, Craig
Re: Support for Keep-Alive header and timeouts
Hi Aleks, Sorry, I was a bit unclear about the initial request, it was more about the timeout on keep alive connections than the actual support of the Keep-Alive header! I did review the manual for it, the http-keep-alive option isn't the option I'm looking for, as "It will define how long to wait for a new HTTP request to start coming after a response was sent.". This makes it more of an 'idle timeout'. I'd like the ability to, after exactly (for example) 10 minutes, forcibly close the client socket regardless of it's current state or what it's doing. All the timeouts I've found in haproxy seem to related more to 'idle timeouts': * timeout http-keep-alive - Amount of time until a socket is closed because it's been idle and hasn't sent a request * timeout client - Amount of time until a socket is closed because it's expected to send data but has been idle for this period. * timeout http-request - Amount of time until a socket is closed because it hasn't sent a complete HTTP request in this time. None of these really provide the type of behaviour I'm expecting, for a small amount of context: >From a firewall perspective all sockets are configured to forcefully stop after about 20 minutes after which time a connection will go 'stale' and no longer function, any additional packets on that socket will be ignored. This is fine for our purposes, but when keep-alive comes into play this raises some problems. Theoretically using all the timeouts available in haproxy it's tentatively possible to maintain a connection for *LONGER* than that period, at which point the connection gets silently dropped, and in haproxy the connection fails in a non-graceful way. Ideally, obviously, I'd like for haproxy to have a way to close the connection as gracefully as possible after X minutes, rather than the current scenario where it may get killed ungracefully. Running v1.6.4 Cheers. On Mon, Apr 25, 2016 at 2:20 PM, Aleksandar Lazic <al-hapr...@none.at> wrote: > Hi. > > Am 25-04-2016 14:01, schrieb Craig McLure: >> >> Hi, >> >> Does HAProxy support the Keep-Alive header, and a 'max connection >> duration' for Keep-Alive connections? >> >> I've poured through the manual, but can't see anything obvious, but it >> would be useful for better control over Keep-Alive connections. > > > please can you show us haproxy -vv > > and maybe this could help > > http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4-timeout%20http-keep-alive > http://cbonte.github.io/haproxy-dconv/configuration-1.6.html#4-timeout%20http-keep-alive > > found it with search in the page. > > There are more keep alive settings on this page ;-) > > Best regards > Aleks
Support for Keep-Alive header and timeouts
Hi, Does HAProxy support the Keep-Alive header, and a 'max connection duration' for Keep-Alive connections? I've poured through the manual, but can't see anything obvious, but it would be useful for better control over Keep-Alive connections. Thanks.
Re: Question about Keep-Alive behaviour
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 haproxy? Thanks. On 22 March 2016 at 20:44, Baptiste <bed...@gmail.com> wrote: > On Tue, Mar 22, 2016 at 2:17 PM, Craig McLure <cr...@mclure.eu> wrote: > > Hi, > > > > I'm hoping to experiment with enabling keep-alive on my service, but the > > documentation isn't entirely clear for my use case, the general > > implementation is as follows: > > > > 1) A HTTP request comes in > > 2) A LUA script grabs the request body, does some analysis on it, and > > injects a Cookie: header into the request > > 3) The request goes to a backend, where the cookie is used to determine > the > > server the request should be dispatched too. > > > > This behaviour seems to work fine with the http-server-close or httpclose > > options, but I'm not entirely sure what would happen in a keep-alive > session > > when the backend server switches. I've set http-reuse to 'safe' but when > > the second request goes to a different backend server to the first, what > > happens to the original socket on the first server? Will it be reused by > > other connections or does it just get dropped in a 1:1 mapping style? > Given > > that it's rare that two subsequent requests on a single connection will > > arrive at the same server, is it even worth having keep-alive support on > the > > backends? > > > > Hopefully you guys can help. > > > > Thanks! > > Hi Craig, > > We miss the backend configuration and how you perform this persistence > to be able to deliver you the best support. > As far as I can tell, the persistence will have precedence over > keep-alive connections, if that helps. So Imagine a client which did a > first request which has been routed to server 1 where the connection > is now established, a second request comes from this same client and > your lua script sets a cookie to point it to server 2, then HAProxy > will close the first connection and establish a new one on the new > server. > > Baptiste >
Question about Keep-Alive behaviour
Hi, I'm hoping to experiment with enabling keep-alive on my service, but the documentation isn't entirely clear for my use case, the general implementation is as follows: 1) A HTTP request comes in 2) A LUA script grabs the request body, does some analysis on it, and injects a Cookie: header into the request 3) The request goes to a backend, where the cookie is used to determine the server the request should be dispatched too. This behaviour seems to work fine with the http-server-close or httpclose options, but I'm not entirely sure what would happen in a keep-alive session when the backend server switches. I've set http-reuse to 'safe' but when the second request goes to a different backend server to the first, what happens to the original socket on the first server? Will it be reused by other connections or does it just get dropped in a 1:1 mapping style? Given that it's rare that two subsequent requests on a single connection will arrive at the same server, is it even worth having keep-alive support on the backends? Hopefully you guys can help. Thanks! -- Craig McLure
