On 26 Nov 2013 12:26, "Chris Burroughs" <chris.burrou...@gmail.com> wrote: > "Highly threaded Java apps" happens to be what most of our servers are used for and what we benchmarked for purchasing decisions. > > >>> Finally assuming the single process performance can not be further >>> improved I was considering the following setup: >>> * core 0: eht0 interrupts >>> * core 1: haproxy bound to eth0 >>> * core 2: eth1 interrupts >>> * core 3: haproxy bound to eth1 >>> * core 4-5: ssl terminator >> >> >> I definitely agree. I know at least one setup which runs fine this way. >> It was a two-socket system, each with its own NIC and process. But here >> you're in the same situation, consider that you have 3 independant CPUs >> in the same box. The benefit of doing it this way is that you can still >> parallelize network interrupts to multiple cores without having the >> response traffic come to the wrong core (proxies are a hell to optimize >> because of their two sides). >> > > This setup (haproxy per NIC) was able to handle 50% more load than a single haproxy. So from about 20k req/s to 30k. This is very nice bump with with what would otherwise be mostly idle cpu cores. We found this to be very complex to setup at the IP layer though (which isn't haproxy's fault but in our particular circumstances might not be worth it). > > >> >>> But I could not find too many examples of similar setups and was unsure >>> if it was a viable long term configuration. >> >> >> Yes it is viable. The only limit right now is that you'll need to start >> two processes. In the future, when listeners reliably support the >> "bind-process" keyword, it will even be possible to centralize >> everything and have a dedicated stats socket for each. >>
Chris it sounds like we are in a very similar business given I'm in the process of tuning almost the same case... Have a look at our patch we sent to the list a few days or so ago providing a stats socket power process. Depending on your use case it might provide what you need... But note it still has the other issues with nbproc > 1 such as losing peers, sticky take issues for sessions, etc
