Quantos processos devo especificar em um WSGIDaemonProcess enquanto estiver executando o Django através de mod_wsgi?

Question

Digamos que eu tenha 2 sites (Superuser e Serverfault) sendo executados em seu próprio host virtual Apache em uma caixa. Os dois sites são alimentados pelo Django e estão sendo executados no Apache com o mod-wsgi. Um arquivo de configuração típico de um site será parecido com o seguinte:

WSGIDaemonProcess serverfault.com user=www-data group=www-data processes=5

O host é uma máquina linux com 4GB de RAM rodando Ubuntu. Alguém pode sugerir o número de processos que devo especificar acima para meus dois sites? Vamos supor que eles tenham o mesmo tráfego que os sites reais Superusuário e Servidor.

    

Answer 1

Bem, quanto tráfego faz os sites reais Superuser e Serverfault? Hipotéticos não são muito úteis se não tiverem informações suficientes para tornar a resposta mais fácil ...

Sua contagem de processos de pior caso deve ser o número máximo de solicitações por segundo que você deseja que o site possa manipular, dividido pelo número de solicitações por segundo que um processo pode processar se todas essas solicitações forem feitas na sua menor lentidão ação (de modo que o recíproco do tempo de processamento dessa ação). Adicione o fator de correção que achar adequado, com base no intervalo de confiança de suas medidas de tempo e resposta.

A contagem média de casos é a mesma, mas você divide o req / seg pela média ponderada de suas solicitações por segundo para cada ação (o peso é a porcentagem de solicitações que você espera atingir essa ação específica). Mais uma vez, os fatores fudge são úteis.

O limite superior real de quantos processos você pode executar na máquina é ditado pela quantidade superior de memória que cada processo leva; execute um processo em spool, em seguida, execute uma variedade de ações famintas por memória (aquelas que recuperam e processam muitos dados, geralmente) com um conjunto de dados realístico (se você usar um conjunto de dados de brinquedo para teste, digamos 50 ou 100 Se uma de suas ações recuperar e manipular todas as linhas da tabela, não será uma boa medida para quando essa tabela aumentar para 10.000 linhas) para ver o que o uso de memória gera. Você pode restringir artificialmente o uso de memória por processo com um script que coleta trabalhadores que atingem um determinado limite de uso de memória, com o risco de causar problemas desagradáveis se você definir esse limite como muito baixo.

Uma vez que você tem a sua figura de uso de memória, você deduz uma certa quantidade de memória para a sobrecarga do sistema (eu gosto de 512MB eu mesmo), deduzir uma pilha mais se você tiver outros processos rodando na mesma máquina (como um banco de dados) , e mais um pouco para garantir que você não fique sem espaço no cache de disco (depende do tamanho do seu conjunto de trabalho do disco, mas novamente eu iria com nada menos que 512MB). Essa é a quantidade de memória que você divide pelo uso de memória por processo para obter o limite máximo.

Se o número de processos necessários para atender a carga de pico for maior que o número de processos que você pode ajustar na caixa, precisará de mais máquinas (ou para mover o banco de dados para outra máquina, no caso mais simples). / p>

Aí está você, vários anos de experiência expandindo sites destilados em um pequeno e simples post de SF.

    

Answer 2

A resposta do

womble é incrível, apesar de ser um pouco difícil de entender e aplicar aos 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 em torno de definir diferentes casos de uso em relação à sua configuração apropriada de mod_wsgi, então espero que não haja problema em usar um pouco de prosa aqui.

A) Sites & Microsites

Executamos vários sites de clientes, a maioria deles principalmente sites de conteúdo ou micro sites que hospedam o django CMS, alguns formulários personalizados e, às vezes, o Celery para tarefas em segundo plano agendadas. Esses sites não estão com fome de recursos, vários deles rodam alegremente em paralelo em um único Intel Core Xeon 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 Staging em execução no modo de espera. Com dois processos (com 15 threads cada, por padrão), os sites estão bem, embora limitados em sua capacidade de alocar recursos do servidor. Por que essa configuração é suficiente pode ser justificada com a natureza simples do aplicativo (CMS): nunca é esperado que a solicitação leve mais do que alguns milissegundos para ser concluída. O Apache sempre ficará relaxado e assim será a carga da CPU.

B) Sites de comércio eletrônico

Mais sites complexos que fazemos são caracterizados por operações locais ainda computacionalmente baratas, mas dependências externas (por exemplo, serviços da Web que fornecem dados de reserva) que são caras em termos de tempo de transação. As operações com solicitações externas ocupam os encadeamentos por muito mais tempo, portanto, você precisa de mais encadeamentos para atender ao mesmo número de usuários (em comparação com um site CMS simples acima). Pior ainda, os threads 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 desagradável efeito colateral que encadeia as solicitações de colocação na mesma fila de serviço, até que todos os encadeamentos mod_wsgi disponíveis sejam usados e bloqueados em espera.

Para esses cenários, tentamos usar 6 processos sem ver muita diferença e acabamos com 12 vendo um aumento incomparável no desempenho e na estabilidade operacional:

WSGIDaemonProcess example.com user=www-data processes=12 maximum-requests=100

Alguns testes de carga simples com 150 e 250 usuários paralelos são facilmente manipulados pelo site, ficando bem responsivos (enquanto com 2 processa o site é inutilizável, atendendo 50 usuários em paralelo). O Intel Core Xeon de 2 CPUs com 32 GB de RAM está bem abaixo de 25% do uso da CPU sob essa carga, o uso de RAM quase permanece constante em menos de 25% também. Observe que usamos uma máquina dedicada apenas para um único site aqui, para que não roubemos recursos que outros sites possam precisar.

Conclusão

Usar um número maior de processos é um compromisso entre permitir que o Apache faça uso dos recursos do sistema disponíveis ou não. Se você quiser manter um sistema de servidor estável (não site!) Sob condições de "ataque", mantenha o número baixo. Se você quiser que o Apache o ajude usando recursos do sistema (CPU, RAM), quando necessário, escolha um número maior. Quão alto você pode ir calcula algo como descrito na resposta aceita acima, e é limitado pela potência da CPU e pela RAM disponíveis.

(PS: Eu mantenho a seção ConfigurationDirectives do wiki do projeto modwsgi sob meu travesseiro para Além disso, certifique-se de entender e monitorar suas conexões abertas do servidor Apache .