No passado, o servidor OpenERP estava usando threads para lidar com pedidos HTTP simultaneamente ou para processar tarefas agendadas. Usando segmentos ainda é o comportamento padrão ao executar o
openerp-server
script, mas não o recomendado: é, de fato, recomendado usar o
--workers
opção. Ao utilizar o
--workers
opção, o servidor OpenERP vai gerar um número fixo de processos em vez de desova uma nova thread para cada solicitação de entrada.
Isto tem um número de vantagens:
Processos não sofrem da Global Interpreter Lock CPython. Os processos podem ser reciclados graciosamente enquanto os pedidos ainda são manipulados pelo servidor. Recursos como tempo de CPU e memória disponível para um processo pode ser monitorado em uma base por processo.
Ao usar os
--workers
opções, dois tipos de processos pode ser gerado: processo web, eo processo cron.
Novo na versão 7.1.
Ao usar os
--workers
opções, três tipos de processos podem ser gerados: processo web, e o processo cron, assim como materialização, mas também uma evented (usando GEvent) processo web é iniciado. Ele é usado por muito tempo-polling conforme a necessidade do próximo característica Instant Messaging. Por enquanto, esse processo está escutando em uma porta diferente do que os principais processos da web. Um proxy reverso (por exemplo, Nginx) para escutar em uma porta exclusiva, mapeando todos os pedidos para a porta normal, mas o mapeamento do
/longpolling
rota para o processo evented é necessário (a interface web não pode emitir pedidos de portas diferentes). (É possível fazer o evented servidor roscado, passando a
--gevent
. bandeira)
O objetivo é perder o suporte para o modelo de rosca, e também fazer todos os processos web evented; não haveria mais distinção entre processos "longpolling" "normal" e. Para que isso aconteça, é necessário mais testes.