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
