Scripts CGI em escala de Python [fechados]

Question

Eu tenho o Apache rodando em um servidor Ubuntu quad-core em um ADSL de 384kbps. Os arquivos são enviados pelos usuários por meio de um formulário da web e processados por vários programas em Python executados como scripts CGI. Alguns scripts usam muita CPU e são executados a 100% (em um núcleo) por alguns minutos; eles enviam os resultados por e-mail ao usuário para que a sessão HTTP não seja mantida aberta. Alguns scripts exigem que arquivos maiores (total de alguns MB) sejam enviados. Atualmente, o uso é muito baixo, com um punhado de acessos por dia e pouquíssimas instâncias, se houver, ou mais do que o usuário que faz uso dos serviços ao mesmo tempo. Preciso disponibilizar esses serviços para um número maior de usuários no médio prazo.

Eu suspeito que a infra-estrutura que eu construí não se presta facilmente ao dimensionamento. Por exemplo, um usuário solicitou que eu permitisse o upload de vários arquivos para o programa intensivo da CPU. Isso significa que a máquina ficará ocupada por um longo período de tempo. Se outro usuário também enviou vários arquivos para o mesmo script, a máquina pode ficar muito ocupada por um período ainda maior.

Eu sei que perguntas do tipo discussão não são permitidas aqui, então eu gostaria de fazer as seguintes perguntas específicas:

Quais estratégias ou abordagens eu preciso considerar ao tornar esses serviços escalonáveis - ou seja, preciso repensar a infraestrutura completamente?

Se eu não fizesse alterações e 10 pessoas enviassem 10 arquivos para o programa intensivo de CPU, por exemplo, todos os 10 tópicos criados pelo script CGI seriam executados de forma feliz (se lentamente) em todos os 10 arquivos de entrada? É "seguro" ter um servidor rodando a 100% do uso da CPU por uma ou duas horas ou três?

    

Answer 1

Se o seu python foi bem escrito, e é decentemente modularizado, então não deve ser tão ruim.

O que você precisa fazer é olhar para o Aipo e usá-lo como uma fila de trabalhos.

Quando um usuário envia um arquivo para processamento, ele é enfileirado pelo Celery e depois processado no mesmo servidor ou por um nó de trabalho, quando os recursos estão disponíveis. O aipo é normalmente suportado pelo RabbitMQ ou pelo Redis como o intermediário de mensagens (servidor de filas real), e esses são relativamente fáceis de dimensionar.

No que diz respeito ao retorno de chamada "trabalho completo", há várias opções disponíveis, você ainda pode usar o e-mail ou pode consultar um serviço como Pusher para enviar notificações de volta ao navegador do usuário que fez o envio.

Os servidores são projetados para executar a 80-90% da carga da CPU, na verdade. Quero dizer, é aí que você está aproveitando ao máximo o poder que você coloca (meio).

Eu suspeito que você esteja hospedando isso em casa (daí o uplink lento do ADSL), e que pode ser apenas um desktop reutilizado, que não são adequados para ciclos de trabalho tipo servidor e carregamento.

    

Answer 2

Como ponto de partida, você deve considerar usar a interface WSGI para seu aplicativo e, em seguida, considerar a implementação de alguma biblioteca orientada a eventos assíncronos como Celery ou gevent para programar o logix do aplicativo em tarefas.

CGI é a maneira mais antiga e ineficiente de invocar código externo, tanto de perspectivas de memória quanto de flexibilidade, reconsiderar seu projeto para usar qualquer uma das microestruturas de python (ex. bottle.py ou flask ). dar-lhe um ambiente muito mais stateful para o qual você pode conectar a lógica (seu código python) para trabalhar com as bibliotecas mencionadas anteriormente.