o que é um pool de aplicativos?

Question

Estou lendo este artigo:

link

Ele fala sobre como o Phusion Passenger estende o Apache2 para atuar como um servidor de aplicativos. Quando uma solicitação de HTTP é recebida, o módulo Passageiro de Phusion verifica se a solicitação deve ser tratada por um aplicativo veiculado pelo Phusion Passenger. Nesse caso, o módulo gera um processo para o aplicativo, se necessário. Encaminha a solicitação ao processo de inscrição e encaminha a resposta de volta ao cliente. Para melhorar o processo de desova, o passageiro age como um servidor de spawn que armazena em cache o código do framework Ruby on Rails e o código do aplicativo na memória.

Dessa forma, toda vez que uma nova solicitação chega, quando um processo é gerado, ele faz referência ao código armazenado em cache e gera o processo rapidamente. Mas, apesar do cache, a desova ainda é cara se comparada a uma solicitação http. Portanto, um pool de aplicativos é usado. Eu não entendo o que é um pool de aplicativos. Isto é o que diz:

Spawned application instances are kept alive, and their handles are stored into this pool, allowing each application instance to be reused later. Thus, Passenger has very good average case performance.

O que significa "mantido vivo" e suas "alças são armazenadas neste conjunto". Eu pensei que é o ponto de cache - para manter os dados vivos para mais tarde. Então não vejo como isso é diferente.

    

Answer 1

Os termos "mantidos vivos" e suas "alças são armazenadas neste conjunto" referem-se a algo diferente do armazenamento em cache.

Cache

O armazenamento em cache é um mecanismo em que os dados que são caros de adquirir são mantidos em um local de acesso rápido para reutilização posterior. Você verá isso usado em vários lugares, como:

• procurando algo em um banco de dados
• resolvendo o endereço IP de um servidor
• acessando um arquivo de um disco rígido

Pooling

Os "mantidos vivos" a que se referem na documentação do Phusion Passenger referem-se a forçar um aplicativo a permanecer indefinidamente, para que possamos economizar o tempo necessário para iniciar o aplicativo.

Ao atender a uma solicitação da web, você deseja que o aplicativo seja o mais responsivo possível. Se levar vários segundos para um aplicativo ser iniciado, e depois vários segundos para solicitar dados de um banco de dados, não será possível criar um aplicativo da Web responsivo.

Então, o que é feito é que um frontend leve é construído para aceitar conexões e manter múltiplas instâncias do aplicativo em funcionamento o tempo todo, e então o frontend fará o seguinte:

1. atribua uma conexão de entrada a uma das instâncias já em execução do aplicativo
2. obtenha os resultados desta instância em execução
3. passar os resultados de volta para o cliente
4. coloque a instância em execução do aplicativo de volta em um estado "pronto para processar"

Exemplo

Eu gosto de usar o exemplo de ter vários registros em uma mercearia. Cada pista é uma instância do servidor de aplicativos, e cada um só pode processar um único usuário por vez, mas juntos eles podem atender vários.

Se você der uma olhada no servidor HTTP do Ruby Mongrel ele foi projetado para que possa ser executado em uma piscina da mesma maneira.

One popular configuration was to run Apache HTTP Server 2.2 as a load balancer using mod_proxy_balancer in conjunction with several Mongrel instances. Each Mongrel instance would run on a separate TCP port, configured via the mongrel_cluster management utility. Until recently, Twitter was a notable instance of this configuration.

Mongrel was capable of serving Ruby on Rails powered sites without requiring any other web servers, though as a single-threaded application this configuration is unsuitable for all but light loads

    

Answer 2

Não há uma situação on / off binária acontecendo aqui. É um continuum.

Um extremo do continuum é o antigo modelo de programação web CGI : o servidor web inicia um novo aplicativo para o serviço cada solicitação que entra. O aplicativo morre quando termina de manipular a solicitação. Como o aplicativo precisa recomeçar toda vez, ele precisa recriar o estado do aplicativo em cada solicitação. Isso é caro tanto no tempo quanto no espaço de dados.

Assim, ao longo do tempo, muitas opções foram criadas para reduzir a despesa:

• FastCGI usa o modelo CGI, mas mantém o programa CGI ativo após iniciá-lo pela primeira vez, e apenas continua alimentando novos pedidos para ele. Isso não só evita a despesa de relançar o programa CGI, como também permite que o aplicativo mantenha o estado na RAM.

• mod_{perl,php,ruby,...} traz o intérprete de aplicativo real para a instância do servidor web, e esses sistemas tendem a fazer o mesmo tipo de coisas que o FastCGI faz: após carregar e compilar cada script para algum tipo de bytecode , apenas alimenta novas solicitações sem refazer todo o trabalho.

• Esse sistema que você está falando é apenas um nível maior do que o esquema mod_foo , onde ele mantém um modelo lógico de um aplicativo inteiro na RAM, de modo que menos coisas precisam ser recriadas em cada pedido. Exatamente como isso difere do comportamento base que você obtém com mod_foo eu não poderia dizer. O ponto, entretanto, é que não é uma diferença na qualidade, apenas da quantidade.

• O próximo passo, que pode ajudá-lo a entender onde este Phusion Passenger está tentando ir, é manter tudo funcionando dentro de uma única instância de aplicativo de longa duração. É assim que funcionam os servidores Web baseados no Erlang , como Nitrogênio . Visite esse segundo link para uma comparação com a maneira como os aplicativos baseados em Apache funcionam.

  Acredito que muitos servidores de aplicativos baseados em Java funcionam da mesma maneira.

Resumindo, tudo isso é um jogo de otimização, trocando a RAM e a complexidade do tempo de execução pela velocidade.