2011/10/19 wsq003 <wsq...@sina.com>: > Hi > > In manual there is following: > > nbproc <number> > Creates <number> processes when going daemon. This requires the "daemon" > mode. By default, only one process is created, which is the recommended mode > of operation. For systems limited to small sets of file descriptors per > process, it may be needed to fork multiple daemons. USING MULTIPLE PROCESSES > IS HARDER TO DEBUG AND IS REALLY DISCOURAGED. See also "daemon". > > > My question is how DISCOURAGED is it? Here we need to handle a lot of small > http request and small response, and haproxy need to handle more then 20k > reuquests per seconds. Single process work in single CPU seems not enough. > (We may add ACL config in the future, and haproxy would be even busier.) > > So, I want to set nbproc to 4 or 8. > > For now I know some shortages of multi-processe mode haproxy: > 1, it would cause many context switch (after testing, this is acceptable) > 2, it would become difficult to get status report for every process (we > found some ways to make it acceptable, though it's still painful) > > Is there any other shortage that I do not realize? stick tables wont work as they are per-process.
Main reason is that most of the work is done in kernel (which is multithreaded) so more processes just add more context-switching and make it harder to debug. Usually its at least 3/4 time spent in kernelspace so userspace just have to be fast enougth. Unless you have 24 cores on loadbalancer 1 process should be fine. Some ppl tried binding network card irqs to CPU with good results, or binding haproxy to one core and network irqs to other cores. Try something like 'process' module of collectd, it can show you how much % is used in system/user per process
