Rails应用程序的第一个请求非常缓慢

Question

Rails应用程序的第一个请求非常缓慢

ruby-on-railshttpmongrel

5

我的Rails应用程序的第一个请求（工作会话）总是很慢。切换到生产模式也没有帮助。

我使用mongrel，其他请求的处理速度还可以接受。

我该如何使其更快？

谢谢

- Stefan

5个回答

2

这可能是因为：

需要加载多个插件和gem包
连接外部服务（然后缓存）
缓存自己的页面，只有在第一次请求之后才会发生，除非您“预热”缓存

其中任何一个都不可避免地会增加第一个请求的响应时间。

- MatthewFord

1

这可能是与我们在Websphere中第一次启动应用程序时花费很长时间的原因相同。

当安装新版本的应用程序（或重新启动WAS）时，WAS必须进行大量的初始工作来设置容器。

我们使用的解决方法是修改安装脚本和WAS启动脚本，以便它们在应用程序运行时自动浏览应用程序（主页和选择其他页面）。这样，对它的第一个真正访问就是以全速进行的。

我不知道如何在Ruby中做到这一点，甚至不知道是否可能。你需要自己解决这个问题。

- paxdiablo

可以通过使用简单的脚本来请求所有使用curl/wget的Rails应用程序页面来实现相同的效果。 - Anya Shenanigans

1

我猜你正在使用Ferret进行全文搜索？也许Ferret连接需要一段时间来初始化？当我检查你的日志时，似乎数据库和视图都需要正常的时间，但总共仍然需要10秒。所以我认为可能是其他问题，因此我猜测Ferret可能是问题所在。

- Maran

1

也许你需要调整 Apache 配置文件中的 PassengerPoolIdleTime 变量。将其设置为 0，以便永远不会停止 Rails 进程。

- Sidhannowe

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Chris McCauley · Accepted Answer

如果您在处理第一个请求时发布日志内容，那么也许我们可以找出是什么使它变得如此缓慢。例如，这是我的日志，当第一个用户访问该网站时。

Booting Mongrel (use 'script/server webrick' to force WEBrick)    
Rails 2.1.0 application starting on http://0.0.0.0:3000    
Debugger enabled    
Call with -d to detach    
Ctrl-C to shutdown server
** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment...
/usr/lib/ruby/gems/1.8/gems/actionpack-2.1.0/lib/action_controller/mime_type.rb:66: warning: already initialized constant CSV
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready.  TERM => stop.  USR2 => restart.  INT => stop (no restart).
** Rails signals registered.  HUP => reload (without restart).  It might not work well.
** Mongrel 1.1.5 available at 0.0.0.0:3000
** Use CTRL-C to stop.


Processing SessionsController#new (for 127.0.0.1 at 2009-05-26 12:26:00) [GET]
  Session ID: de2acf074759026e1ed6205724f547a9
  Parameters: {"action"=>"new", "controller"=>"sessions"}
Rendering sessions/new
Completed in 0.00587 (170 reqs/sec) | Rendering: 0.00298 (50%) | DB: 0.00092 (15%) | 200 OK [http://localhost/]

我认为我们的应用程序每秒处理170个请求已经足够了，但其他人可能会觉得这很慢。从Rails提供的统计数据可以看出，需要的一半时间用于渲染响应 - 在这种情况下是生成登录屏幕的HTML。如果这个请求花费了很长时间，我的第一个查找点将是与登录屏幕相关的视图和助手。

如果您确实有一个在第一个请求上初始化自身需要很长时间的系统，那么为什么不狡猾地编写自己的启动程序，先运行Rails，然后通过curl发送一个虚假请求呢？这样，您的用户就永远看不到问题了。

克里斯