Como faço solicitações HTTP em Rails enquanto ainda atendem muitas solicitações por minuto?

Question

Estou tentando ampliar um servidor de aplicativos para processar mais de 20.000 solicitações por minuto.

Quando eu estresse - teste as solicitações, a maioria dos pedidos é facilmente lidar com 20.000 rpm ou mais.

mas, solicita que necessitam de fazer uma solicitação HTTP externa (por exemplo, Login do Facebook) traga o servidor para um rastreamento (3.000 rpm).

Eu conceitualmente entendo as limitações do meu ambiente atual - 3 servidores balanceados de carga com 4 trabalhadores de unicórnio por servidor só podem lidar com 12 solicitações de cada vez, mesmo que todos estejam aguardando solicitações HTTP.

Quais são as minhas opções para dimensionar isso melhor? Eu gostaria de lidar com muitas mais conexões de uma só vez.

possíveis soluções como eu entendo:

.

1. força bruta: use mais trabalhadores de unicórnio (ou seja, mais RAM) e mais servidores.

2. Empurre todas as operações de bloqueio em processos de fundo / trabalhador para liberar os processos da web. Os clientes precisarão pesquisar periodicamente para encontrar quando sua solicitação for concluída.

3. Mova-se para Puma em vez de Unicórnio (e provavelmente para Rubinius da MRI), para que eu possa usar threads em vez de processos - que podem (?) melhorar o uso de memória por conexão e, portanto, permitir o número de trabalhadores a serem aumentados.

Fundamentalmente, o que estou procurando é: Existe uma maneira melhor de aumentar o número de solicitações bloqueadas / fileiras que um único trabalhador pode manipular para que eu possa aumentar o número de conexões por servidor?

Por exemplo, eu ouvi a discussão sobre o uso de fino com a Eventmachine. Isso abre a possibilidade de um trabalhador de trilhos que pode colocar a solicitação da Web que está atualmente trabalhando (porque aquele está esperando em um servidor externo) e, em seguida, pega outra solicitação enquanto ela está esperando? Em caso afirmativo, é uma avenida que vale a pena buscar o desempenho em comparação com o Unicorn e o Puma? (Depende fortemente das atividades de tempo de execução do aplicativo?)

Answer 1

Unicorn é um servidor de aplicativos síncrono multi-processo de rosca única.Não é uma boa partida para este tipo de processamento.

Parece que sua inscrição é I / O limite.Isso argumenta para um daemon orientado para eventos para processar suas solicitações.

Eu recomendo tentar EventMachine e a solicitação EM-HTTP e EM-HTTP-server .

Isso permitirá que você atenda as duas solicitações de entrada para o servidor HTTP e as chamadas de serviço HTTP de saída de forma assíncrona.