Hi Lukas, thanks for your reply. I have a couple followup questions regarding maxconn below.
On Sun, Mar 24, 2013 at 7:06 AM, Lukas Tribus <[email protected]> wrote: > > Hi Nick, > > >> For maxconn, in defaults. I read a lot of places that this value >> depends on the ulimit value of the system, but it's not clear in what >> way they are related. > > suppose you set maxconn [1] to 2000. This means you can have up to 2000 > concurrent session on the haproxy (!) process (frontend + backend). > > You need of course at least the same number of file descriptors, > which is why ulimit will be adjusted _automatically_ [2]. So you > don't need to worry about ulimit, just configure an appropriate > maxconn value. So you are saying that by using the maxconn property in the global config block HAProxy is automatically adjusting the systems ulimit setting? or that if you use ulimin-n, in conjunction with maxconn, whatever value ulimin-n is set to is what is set on the system? In which case you'd do: global maxconn 4096 ulimin-n 4096 Is that correct? - Also, what's a generally effective approach at deciding what to set your maxconn to? - And, do all your frontend maxconn directives need to add up to, and not surpass, your global maxconn value? Thanks for the answer on nbproc as well, that cleared things up. Cheers, Nick > > >> .. as for nbproc. After reading the docs, I got the impression that >> for a normal server nbproc shouldn't need to be used. So is it not >> recommended to set this property at all for most cases? > > You are right. nbproc has a few disadvandges, it's usually not needed > and discouraged. > > With features like tcp splicing, most of the work is done in the > kernel and in fact 10Gbit/s and 20Gbit/s of throughput can been reached > with a single process (and proper tuning, of course). > > Disadvantages are for example, if you configure maxconn --> 2000 (which is > a per process limit), and then bump the nbproc from 1 to 4, you will have > 4x 2000 possible concurrent sessions on this box, so the configuration > becomes more complicated, less flexible and the error potential grows. > > I also believe collecting statistics is a bit harder, as you need to > fetch them from every single process. > > Debugging of problems is a lot harder also. > > Scheduling and context switching may become a problem as well. > > > In the end of the day, you don't want to use multiple processes, expect > for very specific configurations (like heavy user-space load because > of ssl and gzip on the proxy, but then again, probably your design needs > some adjustments). > > > If you need to decide whether or not to use multiple processes, take > a look at your system and userspace load first. Do you really spend > a lot of time in user-space? If thats the case, you should troubleshoot > it and tune it instead of counteracting it with multiple processes. > > > > HAproxy has a lot of options, but to accomplish good performance > you really don't need to set them all, in fact, most of the options > have good and sane defaults, or are automatically adjusting. > > I also believe a lot of problems just come up because users are > configuring options they don't understand and haven't lookup in the > manual. > > > > Regards, > Lukas > > > [1] http://cbonte.github.com/haproxy-dconv/configuration-1.4.html#3-maxconn > [2] http://cbonte.github.com/haproxy-dconv/configuration-1.4.html#ulimit-n > >
