回答
如果您在处理第一个请求时发布日志的内容,那么或许我们可以弄清楚是什么让它变得如此缓慢。例如,这是我的日志作为第一个用户访问该网站
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发送一个假请求。这样你的用户就不会看到问题。
Chris
这可能是同样的理由,我们的应用程序需要很长的时间,我们第一次踢他们关在WebSphere。
当安装新版本的应用程序(或重新启动WAS)时,WAS必须做许多初始工作来设置容器。
我们使用的解决方法是修改安装脚本和WAS启动脚本,以便它们在运行后立即自动浏览到应用程序(主页面和选定的其他页面)。这样,第一次真正的访问是全速。
我不知道如何用Ruby来做到这一点,甚至是否有可能。你必须找出一个。
这是可能的 - 你可以使用一个简单的脚本来使用curl/wget从所有的rails应用程序请求一个页面来达到同样的效果。 – Petesh 2009-05-26 08:30:11
我猜你正在使用Ferret进行全文搜索?可能是雪貂连接需要一段时间才能初始化?当我检查你的日志时,似乎db和view都需要一段正常的时间,但总数仍然是10秒。所以我一定是别的,这就是为什么我猜测费雷特可能是问题所在。
这可能是因为你是:
要求,并加载了一些 插件和宝石
使得外部 服务的连接(然后缓存)
缓存自己的页面,并且只有在第一次请求后才会发生 ,除非 “加热”缓存
其中任何一个都不可避免地会增加第一个请求的响应时间。
也许你需要在apache conf中调整PassengerPoolIdleTime
var。将其设置为0永不停止您的导轨进程。
- 1. 为什么第一次Rails请求测试非常慢?
- 2. Visual Studio 2015 Web应用程序非常缓慢的请求响应
- 3. 烧瓶应用程序非常缓慢
- 4. 非常缓慢的MySQL请求+ php
- 5. Android webview请求应用程序缓慢
- 6. Heroku中的Rails应用程序启动非常缓慢
- 7. 第一次请求的网页缓慢响应
- 8. Rails应用程序#调用非常缓慢
- 9. 在iPad上第一次调用glDrawArrays的速度非常缓慢
- 10. Flex缓慢的第一个Http请求
- 11. 从lambda函数对dynamodb的请求非常缓慢
- 12. setContentView与包含MapView的布局非常缓慢的第一次
- 13. Winform应用程序的第一个Web请求很慢
- 14. zend社区服务器非常缓慢的第一个请求与OS X 10.6
- 15. Ionic2“ionViewDidEnter”方法第一次非常慢
- 16. 詹金斯第一次访问非常缓慢
- 17. 实体框架非常缓慢加载第一次
- 18. 春季第一次请求很慢
- 19. PictureBox.Load方法从第一次请求缓慢加载图像
- 20. sliksvn第一次犯第二次缓慢
- 21. C#WPF非常缓慢的应用程序启动
- 22. 代表电话是非常缓慢的ipad应用程序
- 23. phonegap应用程序非常缓慢加载网站上的ios
- 24. 我的Play应用程序非常慢
- 25. 找出缓慢Rails请求的原因
- 26. 首先发布到Azure MVC3应用程序非常缓慢
- 27. Azure Web应用程序变得非常缓慢
- 28. Wpf应用程序加载非常缓慢
- 29. Facebook的图形api非常缓慢时提出多个请求
感谢您的提示。这里是我的日志文件:http://pastie.org/private/ih2mpcmjpofp5jmfsvw 有时候,它会持续比1600毫秒更长的时间来回答我的请求。我真的没有线索...... – Stefan 2009-05-26 13:33:27