O que está acontecendo é que seu aplicativo e / ou ApplicationSpawners estão fechando devido ao tempo limite. Para processar sua nova solicitação, o Passenger deve iniciar uma nova cópia do seu aplicativo, o que pode levar vários segundos, mesmo em uma máquina rápida. Para corrigir o problema, existem algumas opções de configuração do Apache que você pode usar para manter seu aplicativo ativo.
Aqui está especificamente o que fiz em meus servidores. O PassengerSpawnMethod e PassengerMaxPreloaderIdleTime são as opções de configuração mais importantes em sua situação.
# Speeds up spawn time tremendously -- if your app is compatible.
# RMagick seems to be incompatible with smart spawning
# Older versions of Passenger called this RailsSpawnMethod
PassengerSpawnMethod smart
# Keep the application instances alive longer. Default is 300 (seconds)
PassengerPoolIdleTime 1000
# Keep the spawners alive, which speeds up spawning a new Application
# listener after a period of inactivity at the expense of memory.
# Older versions of Passenger called this RailsAppSpawnerIdleTime
PassengerMaxPreloaderIdleTime 0
# Just in case you're leaking memory, restart a listener
# after processing 5000 requests
PassengerMaxRequests 5000
Usando o modo de geração "inteligente" e desligando PassengerMaxPreloaderIdleTime, o Passenger manterá 1 cópia do seu aplicativo na memória o tempo todo (após a primeira solicitação após iniciar o Apache). Application
Ouvintes individuais serão fork
removidos desta cópia, o que é uma operação muito barata. Acontece tão rapidamente que você não consegue dizer se seu aplicativo teve ou não que gerar um ouvinte.
Se seu aplicativo for incompatível com geração inteligente, eu recomendo manter um PassengerPoolIdleTime grande e acessar seu site periodicamente usando curl e cronjob ou monit ou algo assim para garantir que o ouvinte permaneça vivo.
O Guia do usuário do passageiro é uma referência incrível para essas e outras opções de configuração.
editar : Se seu aplicativo for incompatível com geração inteligente, existem algumas novas opções que são muito boas
# Automatically hit your site when apache starts, so that you don't have to wait
# for the first request for passenger to "spin up" your application. This even
# helps when you have smart spawning enabled.
PassengerPreStart http://myexample.com/
PassengerPreStart http://myexample2.com:3500/
# the minimum number of application instances that must be kept around whenever
# the application is first accessed or after passenger cleans up idle instances
# With this option, 3 application instances will ALWAYS be available after the
# first request, even after passenger cleans up idle ones
PassengerMinInstances 3
Portanto, se você combinar PassengerPreStart e PassengerMinInstances, o Passenger ativará 3 instâncias imediatamente após o carregamento do apache e sempre manterá pelo menos 3 instâncias ativadas, de modo que seus usuários raramente (ou nunca) verão um atraso.
Ou, se você estiver usando o spawning inteligente (recomendado) PassengerMaxPreloaderIdleTime 0
já, você pode adicionar PassengerPreStart
para obter o benefício adicional da inicialização imediata.
Muito obrigado aos heróis de phusion.nl !