Hi Mikolaj, On Mon, Oct 22, 2012 at 12:24:36PM +0200, Miko??aj Gierulski wrote: > Hi Willy, > you wrote here, that tunnel mode is normally not recommended. > We understand that, but we are looking for the best configuration for our > purposes. > We want to use haproxy as an internal loadbalancer between our frontend and > backend servers. > For some purposes we will need sharding (like loadbalancing by url parameter) > and for some not. > > For the latter we think tunnel mode should be appropriate in the following > scenario: > - the client (which are our frontend servers) establishes several keepalived > connections to haproxy > - haproxy establishes several keepalived connections to backend servers > - the client communicates with haproxy using one of available connections > - the request is delivered to the backend assigned to this connection > > We wonder why is this impossible when the request needs to be analyzed. Our > idea is that the client could use keepalived connections to haproxy, > and also haproxy would use keepalived connections to backend servers. It > would only choose the connection after request analyzis.
The problem is that haproxy will not choose a connection after request analysis, it will analyse the first request on the connection then establish a connection to the server and will let the client and the server talk together on this connection without any further inspection. So if the client wants to post a request for a different URL on the same connection, haproxy will not see it and will continue to forward the traffic to the same server. Also another issue with this setup is that you keep idle connections to servers. This is why end-to-end keep-alive commonly has a negative impact on performance, because it needlessly uses server resources. > Does this make any sense and is such configuration possible? This generally only makes sense for static file servers, because objects are fetched very quickly in a row over the same connection and for static servers, idle connections are cheap. For application servers, it will make sense once haproxy supports server-side keep-alive, because haproxy will be able to switch to another server if the client sends a specific request in an established connection. And it will definitely make sense once haproxy is able to reuse idle connections for different users. But there is still some way to go before this is possible. > If not, what configuration would you recommend? > The closest to this that we could achieve was setting option > http-server-close, which at least allows the clients to use keepalived > connections. This is clearly what I'd recommend : http-server-close. keep-alive is used where it's useful (client is where the latency is) and where it's cheap (many clients, cheap connections to haproxy). Closing on the server is not an issue because generally the server is at 100 microseconds from haproxy so the time to establish the connection is absolutely not noticeable. Also, it maintains server resources at their lowest possible value and allows haproxy to enable queuing if needed to smooth the server load during traffic peaks. Regards, Willy
