this is server with 2x Intel I350-T4 1G Quad port NICs, where on first card each NIC is connected to uplink provider and 2nd NIC 4 ports are used for trunk interface with lacp connected to internal 1Gb switch with lacp configured as well. I've tested uplinks and internal link with iperf and was able to see at least 900Mbps for TCP tests.
Card seems to be OK. Haproxy definitely needs to be moved to separate servers in inside network. Btw, where Pavlos reported his test results? There in list or somewhere else? Thanks again! -- Evgeniy On Mon, Apr 6, 2015 at 12:48 PM, Willy Tarreau <w...@1wt.eu> wrote: > On Mon, Apr 06, 2015 at 12:34:05PM +0200, Evgeniy Sudyr wrote: >> 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. > > OK, I was not sure whether it was the SP kernel or just no nbproc. > >> I can't test to disable PF to test, because it's some kind of production >> router. > > I can understand, the test needs to be run on a test machine. > >> 2) I guess solution is to get separated loadbalancing servers with >> Debian on it and better CPUs and run testing. > > I wouldn't give up too fast with openbsd. It's an excellent OS when you > want a "drop and forget" solution. It's just that it's not very fast. If > you manage to find what is causing this important load, maybe you can > work around it or find some tunables. >> >> 3) What are "good numbers" - I've tried to find some recent benchmarks >> for haproxy on commodity hardware, but not much available. > > Pavlos recently reported 438000 requests/s. I'm used to see about 110-120k > end-to-end connections per second on high frequency Xeon CPUs. Bandwidth > is really cheap these days with the proper NICs : with moderately large > objects (250kB or more) today it's not hard to reach 40 Gbps on a recent > machine equipped with one 40G or four 10G NICs. > > Just thinking about something since you're reporting 250-300 Mbps, I > guess you're running on 1 Gbps NICs. Are you using good quality NICs ? > By good I mean, aren't you running on low-end realteks or similar which > can require significant work on the driver side and thus explain the > high CPU usage in interrupt ? > > Willy > -- -- With regards, Eugene Sudyr
