On 9/12/13 10:47 PM, Willy Tarreau wrote: > On Thu, Sep 12, 2013 at 02:33:10PM -0700, Michael Lasevich wrote: >> On 9/12/13 1:34 PM, Willy Tarreau wrote: >>> I'm sorry but I still don't understand what you're trying to achieve. >>> Having *two* default backends makes no sense, how would we decide >>> which one to use ? If they're both to be used, simply merge both >>> servers :-/ Regards, Willy >> Now, if only HAProxy had load balancing capabilities... ;-) >> >> Basically I need multiple frontends - some go to one backend, some to >> another, some to both. This is easy if you duplicate servers into a >> third backend as you say - but then you have two sets of maxconn - >> meaning you no longer have ability to effectively limit max overall >> sessions to each server. >> >> A specific example is a search server that serves public and private >> data for some customers. A query for public data returns only public >> data, but a query for private data returns private data+public data. Now >> private queries are directed to the cluster the data is at - but public >> queries can be handled by ANY of the servers. Makes sense now? > Yes I get it now, thanks for explaining. I've seen very similar cases > a number of times, and it was always addressed the same way : the > maxconns are reduced in the backends to ensure that their sum does > not surpass the real server's maxconn. It is even possible that in > your case there are far less private requests than public ones, meaning > you can only slightly reduce the maxconn on the public servers. > > I know it can sound like you're limiting the server's capacity by > reducing the maxconn value but in practice this is not the case, as > you'll observe that you get the exact same performance with a wide > range of maxconn values. > > So probably something like this will do exactly what you want, > assuming you're running with maxconn 100 on your servers : > > frontend pub > use_backend all > > frontend pri > use_backend pri > > backend all > server pub1 1.1.1.1 maxconn 90 check > server pub2 1.1.1.2 maxconn 90 check > server pri1 1.1.2.1 maxconn 90 check > server pri2 1.1.1.2 maxconn 90 check > > backend pri > server pri1 1.1.2.1 maxconn 10 track all/pri1 > server pri2 1.1.2.2 maxconn 10 track all/pri2 > > Another concern I'm having with your description, but that is very > specific to your usage, is that I find it strange to let public users > access private servers to retrieve public data. I don't know what > prevents your public users from retrieving private data this way :-/ > > Regards, > Willy > If you read my original message, that is the solution I am using now - but since our load is not even or consistent between the two uses (at some points there are spikes in public usage, other times it is a spike in private usage), the connections are very fast, and the overall maxconn is very low (2), dedicating a set percentage of resources to specific use instead of sharing the load is a bit problematic.
As for maxconn - I have actually done extensive load testing and the short of it is that the server is not very well written. Throttling max concurrent connections on haproxy makes a world of difference in overall performance in this case ( going from 2 to 4, for example doubled the load and doubled the response time) The server is supposed to have a max concurrent connection setting - which is the right solution here, but in my experience it did not work very well. This is purely server problem, but since it is a 3rd party software and we are married to it at the moment, it is a longer term solution, and I was hoping for a quick and easy fix for bad server coding :-/ As for what prevents public users from accessing private data, it is the exact same thing that prevents public users from accessing private data in a DB that contains both sets of data - permissions. (not to mention this is an internal service not exposed directly to users) Thanks, -M
