A resposta de womble é incrível, embora um pouco difícil de entender e solicitar os inexperientes. Gostaria de fornecer alguns números empíricos e comparação de aplicativos "conteúdo simples" versus "comércio eletrônico".
Não há muito material para definir casos de uso diferentes em relação à configuração apropriada de mod_wsgi, portanto, espero que esteja tudo bem em usar uma pequena prosa aqui.
A) Sites e Microsites CMS
Executamos vários sites de clientes, a maioria deles sites de conteúdo ou micro sites que hospedam o django CMS, alguns formulários personalizados e, às vezes, o Aipo para tarefas em segundo plano agendadas. Esses sites não têm fome de recursos, vários deles rodam alegremente em paralelo em um único Intel Xeon de 4 núcleos com 32 GB de RAM. Aqui está a configuração que usamos para cada um desses tipos de sites:
WSGIDaemonProcess example.com user=www-data processes=2 maximum-requests=100
Estou falando de aproximadamente 40 sites em um único servidor, a maioria deles com o site de teste em execução no modo de espera. Com 2 processos (com 15 threads cada, por padrão), os sites estão bem, embora limitados em sua capacidade de alocar recursos do servidor. O motivo pelo qual essa configuração é suficiente pode ser justificado com a natureza simples do aplicativo (CMS): Não se espera que nenhuma solicitação demore mais do que alguns milissegundos para concluir. O Apache sempre permanecerá relaxado, assim como a carga da CPU.
B) Sites de comércio eletrônico
Os sites mais complexos que fazemos são caracterizados por operações locais ainda computacionalmente baratas, mas dependências externas (por exemplo, serviços web que fornecem dados de reserva) que são caros em termos de tempo de transação. As operações com solicitações externas ocupam threads por muito mais tempo, portanto, você precisa de mais threads para atender o mesmo número de usuários (em comparação com um site simples do CMS acima). Pior ainda, os encadeamentos são ocasionalmente bloqueados quando um serviço externo não pode responder a uma solicitação imediatamente, às vezes por alguns segundos. Isso pode levar ao efeito colateral desagradável de que os threads que colocam solicitações na mesma fila de serviço subam até que todos os threads mod_wsgi disponíveis sejam usados e bloqueados a espera.
Para esses cenários, tentamos usar 6processos sem ver muita diferença e acabamos 12vendo um aumento incomparável no desempenho e na estabilidade operacional:
WSGIDaemonProcess example.com user=www-data processes=12 maximum-requests=100
Alguns testes simples de carga com 150 e 250 usuários paralelos são facilmente manipulados pelo site, mantendo uma boa resposta (enquanto nos 2processos, o site é inutilizável, atendendo 50 usuários em paralelo). O Intel Xeon de 2 CPUs e 6 núcleos com 32 GB de RAM funciona bem abaixo de 25% do uso da CPU sob essa carga, o uso da RAM também permanece constante em menos de 25%. Observe que usamos aqui uma máquina dedicada apenas para um único site, para não roubar recursos que outros sites possam precisar.
Conclusão
Usar um número maior de processos é uma troca entre permitir que o Apache faça uso dos recursos disponíveis do sistema ou não. Se você deseja manter um sistema de servidor estável (não o site!) Em condições de "ataque", mantenha o número baixo. Se você deseja que o Apache o ajude a usar os recursos do sistema (CPU, RAM), quando necessário, escolha um número maior. O quão alto você pode ir calcula um pouco como descrito na resposta aceita acima e, em última análise, é limitado pela energia da CPU e RAM disponíveis.
(PS: Eu mantenho a seção ConfigurationDirectives do wiki do projeto modwsgi debaixo do meu travesseiro para leitura em segundo plano semelhante ao Apache. Também não deixe de entender e monitorar as conexões abertas do servidor Apache .)