Eu li toneladas de material na web sobre segurança e desempenho de threads em diferentes versões de ruby e trilhos e acho que entendo essas coisas muito bem neste moment

O que parece estranhamente ausente nas discussões é como realmente implantar um aplicativo Rails assíncrono. Ao falar sobre threads e sincronicidade em um aplicativo, há duas coisas que as pessoas desejam otimizar:

utilizando todos os núcleos da CPU com uso mínimo de RAM poder atender a novas solicitações enquanto as solicitações anteriores estão aguardando IO

@Point 1 é onde as pessoas ficam (com razão) empolgadas com o JRuby. Para esta pergunta, estou apenas tentando otimizar o ponto 2.

Diga que este é o único controlador no meu aplicativo:

TheController < ActionController::Base
  def fast
    render :text => "hello"
  end

  def slow
    render :text => User.count.to_s
  end
end

fast não tem IO e pode atender a centenas ou milhares de solicitações por segundo eslow precisa enviar uma solicitação pela rede, aguardar o trabalho ser concluído, receber a resposta pela rede e, portanto, é muito mais lento quefast.

Portanto, uma implantação ideal permitiria centenas de solicitações parafast a ser cumprido enquanto uma solicitação paraslow está aguardando IO.

O que parece estar faltando nas discussões na Web é qual camada da pilha é responsável por ativar essa simultaneidade. fino tem um--threaded flag, que irá "Chamar o aplicativo Rack em threads [experimental]" - isso inicia um novo thread para cada solicitação recebida? Aplicar spool de instâncias de aplicativos em rack em threads que persistem e aguardam solicitações de entrada?

É magro o único caminho ou existem outros? O tempo de execução do ruby é importante para otimizar o ponto 2?