Re: about nbproc in conf
OoO En ce doux début de matinée du mercredi 19 octobre 2011, vers 08:31, wsq003 wsq...@sina.com disait : 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) I don't know how you do it, but here, we use haproxy for several independant services (say, A, B and C). Service A is bound to processus 1, B to 2 and C to 3. And we declare 3 monitoring backend. Something like this: listen serviceA bind-process 1 listen serviceB bind-process 2 listen serviceC bind-process 3 listen monitoring-1 bind 127.0.0.1:8881 bind-process 1 stats enable stats uri /stats?haproxy listen monitoring-2 bind 127.0.0.1:8882 bind-process 2 stats enable stats uri /stats?haproxy listen monitoring-3 bind 127.0.0.1:8883 bind-process 3 stats enable stats uri /stats?haproxy Since services are independant, they don't need to share anything (like stick tables) and we get stats in CSV format by querying /stats?haproxy;csv on port 8881, 8882 or 8883. -- Vincent Bernat ☯ http://vincent.bernat.im prom_printf(Detected PenguinPages, getting out of here.\n); 2.0.38 /usr/src/linux/arch/sparc/mm/srmmu.c
Re: about nbproc in conf
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
Re: about nbproc in conf
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? Thanks, Hi, The first thing you need to remember before considering going multiprocess is that HAProxy is event-driven, which means that the faster the CPU, the faster HAProxy will be, and this is linear: over a 3GHz CPU, HAProxy will peform 50% faster than on a 2GHz... Second point, consider that ACLs impact on HAProxy as null. Well, for all acls but regexp based, where the impact remains realy low anyway. HAProxy is not able to share its memory between process, so anything related to memory won't work (stats, server maxconn, stick-table, etc) So if you can leave without that, it's fine. On a single process we can go up to 50K at Exceliance. To be fair that's Marketing, since Willy benched the appliance much over this limit :) cheers
