On Thu, 30 Oct 2003, Rene Dudfield <illumen@yahoo.com> wrote:
Threads and processes also can easily use multiple cpus.
This is a common objection, so I thought I will point out the fallacy here: common multiple CPU are on the order of 4, maybe 8, CPUs. Rarely do we get to 64-land, and only for extremely high-end servers. Common web servers are expected to deal with 100s of requests concurrently, and that's the *low-end* stuff. High-end means tens of thousands of requests concurrently. This means (number of requests)>>(number of CPUs). Since you want, for high-performance, for threads (or processes) to get tied to a CPU, the optimal number of runnable processes is #CPUS-1 (this is so the "odd task" will get the free CPU instead of displacing one of the long-running tasks). So, if you really want to use your SMP hardware, the best thing is to set up several servers, one per CPU (minus 1). Twisted can do it, the worst case you'll need to hack up a ten-minute custom IListener and use listenWith, if you don't have more efficient round-robin schemes. If those really need to talk to each other, they can use mmap with the right flags to communicate. There is almost never a reason to use threads here. (The optimal thing would be to divide along URL boundaries, if you have a smart enough reverse-proxy, so that the different servers have as little need to communicate as possible).