5

On a 4-core box which scenario makes the better setup:

4 uWSGI processes with a deep queue to handle requests

8 uWSGI processes with a deep queue

As many many processes as the server's memory allows with the a relatively shallow queue ?

Jason Christa
  • 622
  • 4
  • 11
  • 21

2 Answers2

3

Historically the common wisdom has been that web server performance (which is to say a high-volatility workload with relatively short per-transaction lifetimes) is much more a function of available memory than number of cores. The OS process scheduler will employ considerably deeper magic than just round-robin-ing the most CPU-intensive processes among its available processors; rather than trying to second-guess the scheduler, your better bet is to ensure you've got enough RAM to keep more shallow-queue processes alive than your expected concurrent-request load, and let the scheduler handle how to get them cycles in a timely manner.

Jeff Albert
  • 1,967
  • 9
  • 14
  • I am not 100% sure on this but from observation, it looks like there is a master uWSGI process that is round-robining to the child processes. – Jason Christa Mar 25 '11 at 15:59
  • 1
    Round-robining in what sense? The parent can tell its children how long to live, but it can't specify on what processor they should execute their instructions. You can set the processor affinity of the children, but that's still just trying to do the scheduler's job for it. – Jeff Albert Mar 25 '11 at 16:31
  • The master process receives the requests and using the round robin approach has a child handle it. The OS then chooses what CPU it runs on. It is obvious that there has to be at least as many processes as there are CPUs for good utilization. I am wondering if creating more processes lets has extra advantages (like letting the scheduler more finely distribute the workload) or if it is an un-needed optimization. – Jason Christa Mar 25 '11 at 18:37
  • 1
    My assertion is that more processes, to the limit of your usable memory, is a bonus because it allows you to handle large, unpredictably-frequent spikes of requests without the pain of dynamic process allocation. – Jeff Albert Mar 25 '11 at 23:14
1

The answer is that it depends on the application you're serving and in particular the runtime.

If you're using Python or Ruby then you will probably want one process per logical core – unless your application uses a lot of native code that is able to use multiple cores.

If you're using Go or another language that is able to run code concurrently on multiple cores then you need only a single process.

As for whether you need a deep or shallow queue (socket listen queue length), this needs to be at least as long as the number of processes x number of threads and longer depending on what's in front of uWSGI.

malthe
  • 196
  • 4