On 11/15/2014 5:43 AM, Baptiste wrote: >> Looking at that URL, a similar CPU to mine, but a little faster, >> Intel(R) Celeron(R) CPU 440 @ 2.00GHz, shows a termination rate of over >> 300 per second. My CPU is 1.8 Ghz. Another difference is that I have >> 2048 bit certificate, the test was 1024 bit. > > this CPU looks quite weak for SSL processing. > That said, for a few hundreds of reqs per second, it should be enough. > Hopefully you won't have too many SSL keys to compute!
Thank you for taking time to help me. We did some sampling of the logs for one Apache virtualhost, which is one of the busy ones. I came up with about 15 requests per second for that instance, and that particular site isn't SSL. Extrapolating across multiple sites (most of which are not as busy), I would expect our total request rate to be somewhere around 100-150 per second, with a small subset of those being SSL. More sampling will be required. One piece of concrete information I have is the number of packets per second for the busiest back-end webserver (graphed by Xymon): https://www.dropbox.com/s/r1fn5uwd3tp3r9g/tcp-graph-webserver.png?dl=0 I don't know exactly how Xymon computes this graph, so I don't know if this is all ethernet interfaces or just the primary. One interface (eth0.250) is used for access to our new storage system. Another (eth0.811) is used for access to the older storage, the database, the search engine, and other miscellaneous resources. The last interface (eth1) has the default gateway and is where traffic from LVS (hopefully migrating to haproxy) goes. The eth0 interface is gigabit, but I'm fairly sure the eth1 interface is 100Mb. Here's some graphs from the current load balancer, with most of the traffic going through LVS, but some of it using two SSL front ends on haproxy, talking to SSL back ends: https://www.dropbox.com/s/yeaeobs9tbvqw3e/lb1-pps.png?dl=0 https://www.dropbox.com/s/5nxcmetuxtph3o8/lb1-bandwidth.png?dl=0 https://www.dropbox.com/s/qly2r9jleod5bp2/lb1-cpu.png?dl=0 I'm well aware that in the long term, the existing load balancer with its Celeron CPU is not going to be enough. My hope is that what I've already got might be good enough for the next few months. Further questions: When haproxy utilizes multiple processes, are there any pitfalls with shared memory resources, or does that work reliably and quickly? Because of potential problems with NUMA, I would only use a single-socket server, but I'd like to know whether I should invest in a lot of cores and go multi-process, or only use one haproxy process on a cheaper (dual or quad-core) fast CPU. Do you have any general CPU recommendations? Thanks, Shawn
