使用Phusion Passenger和Rails时，初始服务器启动缓慢 [英] Slow initial server startup when using Phusion Passenger and Rails

问题描述

为了跳上Phusion Passenger的旅行车，我们为一个小型跑车应用程序设置了一个分段服务器来测试出来。

到目前为止非常好用，它使得安装/配置和部署应用程序变得轻而易举。问题是我们使用的网站不会经常打击，似乎在后台关闭服务器。意思是当有人去网站时，他们有一个很长的等待，直到它启动一个新的服务器来处理请求。我们已经阅读了文档，尝试了不同的设置（smart / smart-lv2模式，乘坐时间等），仍然没有找到真正的解决方案。

在浏览Google搜索结果后，我们找不到有用的信息。目前，我们有一个cron工作，每次都经常发出请求，以防止服务器运行。

有没有人遇到这个问题，你有没有建议修复？

解决方案

发生的情况是您的应用程序和/或应用程序创建者因超时而关闭。为了处理您的新请求，Passenger必须启动您的应用程序的新副本，这可能需要几秒钟，即使在快速的机器上。要解决此问题，您可以使用一些Apache配置选项来保持应用程序的生效。

具体来说我在我的服务器上做了什么PassengerSpawnMethod和PassengerMaxPreloaderIdleTime是您的情况下最重要的配置选项。

 ＃极大地加快产卵时间 - 如果您的应用程序兼容。 
＃RMagick似乎与智能生成不兼容
＃旧版本的乘客称为RailsS​​pawnMethod 
 PassengerSpawnMethod smart 
 
＃保持应用程序实例更长时间。默认值为300（秒）
 PassengerPoolIdleTime 1000 
 
＃保持生成器的生存，加快了在一段时间的闲置后产生一个新的应用程序
＃监听器，以牺牲内存为代价。 
＃Passenger的旧版本称为RailsAppSpawnerIdleTime 
 PassengerMaxPreloaderIdleTime 0 
 
＃为了防止内存泄漏，请在处理5000个请求
＃后重新启动
＃
 PassengerMaxRequests 5000 
  

通过使用智能产卵模式并关闭PassengerMaxPreloaderIdleTime，Passenger将保留1份副本的应用程序在内存中（始于Apache之后的第一个请求之后）。个人应用程序监听器将从该副本 fork 编辑，这是一个超级便宜的操作。它发生得很快，你无法判断你的应用程序是否不得不产生一个监听器。

如果你的应用程序与智能产卵不兼容，我建议保持一个大型PassengerPoolIdleTime，并定期使用curl和cronjob或monit或某些东西来定位您的网站，以确保监听者保持活着。

乘客用户指南是对这些和更多配置选项的真棒参考。

编辑：
如果您的应用与智能生成不兼容，则有一些新选项非常好

 ＃当apache启动时，自动打到你的网站，这样你不必等待
＃来首次请求乘客旋转你的应用程序。即使
＃有助于启用智能产卵。 
 PassengerPreStart http://myexample.com/ 
 PassengerPreStart http://myexample2.com:3500/ 
 
＃每当$的$最小数量的应用程序实例， b $ b＃应用程序首次访问或乘客清理空闲实例后
＃使用此选项，在
＃第一个请求之后，3个应用程序实例将始终可用，即使乘客清理空闲的
 PassengerMinInstances 3 
  

所以，如果你结合PassengerPreStart和PassengerMinInstances，Passenger将立即启动3个实例在apache加载之后，并且将始终保持至少3个实例，所以您的用户很少（如果有的话）看到延迟。

或者，如果您使用智能已经有 PassengerMaxPreloaderIdleTime 0 的产卵（推荐），您可以添加 PassengerPreStart ，以获得立即启动的额外好处。 p>

非常感谢 phusion.nl ！

To jump on the band-wagon of Phusion Passenger we've setup a staging server for a small rails app to test things out.

So far it has been very nice to use, it makes installing/configuring and deploying apps a breeze. The problem is the site we're using doesn't get hit very often and it seems to shut down the servers in the background. Meaning when someone goes to the site they have a really long wait until it starts up a new server to handle the request. We've read through the documentation, tried quite a few different set-ups (smart/smart-lv2 modes, passengeridletime etc) and still haven't found a real solution.

After ploughing through Google results we can't really find useful information. Currently we have a cron job that makes a request every-so-often in an attempt to keep the servers running.

Is anyone else experiencing this problem and do you have any advice for a fix?

解决方案

What's happening is that your Application and/or ApplicationSpawners are shutting down due to time-out. To process your new request, Passenger has to startup a new copy of your application, which can take several seconds, even on a fast machine. To fix the issue, there are a few Apache configuration options you can use to keep your Application alive.

Here's specifically what I've done on my servers. The PassengerSpawnMethod and PassengerMaxPreloaderIdleTime are the configuration options most important in your situation.

# 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

By using "smart" spawning mode and turning off PassengerMaxPreloaderIdleTime, Passenger will keep 1 copy of your application in memory at all times (after the first request after starting Apache). Individual Application listeners will be forked from this copy, which is a super-cheap operation. It happens so quickly you can't tell whether or not your application has had to spawn a listener.

If your app is incompatible with smart spawning, I'd recommend keeping a large PassengerPoolIdleTime and hitting your site periodically using curl and a cronjob or monit or something to ensure the listener stays alive.

The Passenger User Guide is an awesome reference for these and more configuration options.

edit: If your app is incompatible with smart spawning, there are some new options that are very nice

# 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

So, if you combine PassengerPreStart and PassengerMinInstances, Passenger will spin up 3 instances immediately after apache loads, and will always keep at least 3 instances up, so your users will rarely (if ever) see a delay.

Or, if you're using smart spawning (recommended) with PassengerMaxPreloaderIdleTime 0 already, you can add PassengerPreStart to get the additional benefit of immediate startup.

Many thanks to the heroes at phusion.nl!

这篇关于使用Phusion Passenger和Rails时，初始服务器启动缓慢的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！