Hi Willy, pleasure for me to get answer from you!
1) I've tested with OpenBSD's SP kernel and single process (no nbproc) in haproxy.conf and it was no significant difference in load. I can't test to disable PF to test, because it's some kind of production router. 2) I guess solution is to get separated loadbalancing servers with Debian on it and better CPUs and run testing. 3) What are "good numbers" - I've tried to find some recent benchmarks for haproxy on commodity hardware, but not much available. -- Evgeniy -- Evgeniy On Mon, Apr 6, 2015 at 11:59 AM, Willy Tarreau <w...@1wt.eu> wrote: > Hi Evgeniy, > > On Sun, Apr 05, 2015 at 06:29:53PM +0200, Evgeniy Sudyr wrote: >> Nenad, >> >> thank your answer! >> >> 1) this is only Haproxy server active (active/passive config exists, >> but using carp on OpenBSD). >> >> 2) As I understand with nbcproc 4 I can't get stats working correctly ... >> >> however at the moment I see that for https frontend I have : >> Current connection rate: 58/s >> Current session rate: 53/s >> Current request rate: 124/s >> >> For http frontend: >> Current connection rate: 240/s >> Current session rate: 240/s >> Current request rate: 542/s > > These numbers are really low. > >> >> 3) current top output (total in/out for HTTP/HTTPs traffic on external >> interfaces is avg 300 Mbps and this is only Haproxy traffic): >> >> load averages: 4.02, 3.92, 3.88 >> router2 19:28:18 >> 32 processes: 1 running, 27 idle, 4 on processor >> CPU0 states: 12.6% user, 0.0% nice, 11.2% system, 60.9% interrupt, 15.4% >> idle >> CPU1 states: 25.2% user, 0.0% nice, 47.0% system, 0.2% interrupt, 27.6% >> idle >> CPU2 states: 25.1% user, 0.0% nice, 43.3% system, 0.6% interrupt, 30.9% >> idle >> CPU3 states: 21.6% user, 0.0% nice, 48.2% system, 0.2% interrupt, 30.0% >> idle >> Memory: Real: 1017M/1709M act/tot Free: 14G Cache: 111M Swap: 0K/16G > > This huge CPU usage in interrupt definitely reminds me of performance issues > related to pf I used to face a long time ago. The performance would double > or triple just after issuing "pfctl -d" (to disable it). At least it's easy > to test. I've never tested openbsd's network stack in SMP yet, it could be > possible that it comes with some extra cost (for locking or whatever), but > it might be something else as well. > > Regards, > Willy > -- -- With regards, Eugene Sudyr
