如何查明是什么拖慢了我的 Rails 应用程序的速度
我的 Rails 应用程序在开发模式下运行良好（没有缓存），但在生产中很难加载主模型的 :show 视图。日志仅显示 SQL 查询，总计约 45 毫秒，但实际渲染时间约为 15 秒。我正在使用acts_as_ferret和paperclip，但paperclip仅调用after_save循环而不执行任何操作。当时只有 1 或 2 个用户在线，所以我不认为我有备份队列，但我真的无法缩小占用该网站的原因。我可以做什么来更精确地测量服务器端功能并查看是什么在影响加载时间？
在 :show 视图中调用的内容
- 涉及 12 个 HABTM 列表（标签类型、类别等）。
- 找到的相关视频
- 通过 Acts_as_ferret HABTM 视频评论
就这些了。我应该如何将 HABTM 称为 Rails 最佳实践？现在我正在做类似的事情：
<%= @video.tags.map {|t| link_to t.name, path} %>
<%= @video.categories.map {|c| link_to c.name, path} %>
#etc....
我很确定有更好的方法可以做到这一点，并且我愿意接受建议
My Rails app runs fine in development mode (without caching) but in production has a hard time loading the :show view for the primary model. The log only shows SQL queries which add up to about 45ms, but the actual render time is about 15 seconds. I'm using acts_as_ferret and paperclip, but paperclip is only calling the after_save loop to no action. There are only 1 or 2 users online at the time, so I'm not thinking I've got a backed up queue, but I really can't narrow down what's hogging up the site. What can I do to more precisely measure server-side functions and see what is backing up the load time?
Things called in the :show view
- about 12 HABTM lists (types of tags, categories, etc.)
- Related videos found with acts_as_ferret
- HABTM comments for the videos
And that's really pretty much it. And how should I call HABTM as a Rails best practice? Right now I"m doing something like:
<%= @video.tags.map {|t| link_to t.name, path} %>
<%= @video.categories.map {|c| link_to c.name, path} %>
#etc....
I'm pretty sure there's a better way to do this, and I'm open to suggestion
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
以下是一些真正查明瓶颈的工具：
http://newrelic.com/
将在服务器端分析数据库查询时间和 ruby 执行时间等内容
http://developer.yahoo。 com/yslow/
将分析客户端的响应时间、渲染时间和 JavaScript 等内容
没有太多给定的代码可供运行，但有一些内容通常有助于 Rails
find或where：:includes来减少查询次数。:select而不是选择所有列有关该主题的精彩链接：
http://snippets.dzone.com/posts/show/2089
http://www.fortytwo.gr/blog/18/9-Essential -Rails-提示
http://www.engineyard.com/博客/2009/thats-not-a-memory-leak-its-bloat/
Here are a few tools to really pinpoint bottlenecks:
http://newrelic.com/
will analyze things like db query time and ruby execution time on the server side
http://developer.yahoo.com/yslow/
will analyze things like response time, render time, and javascript on the client side
There's not a lot of given code to run with, but there's a few things that generally help in rails
findorwhere::includesto reduce number of queries.:selectrather than selecting all columnsGreat links on the subject:
http://snippets.dzone.com/posts/show/2089
http://www.fortytwo.gr/blog/18/9-Essential-Rails-Tips
http://www.engineyard.com/blog/2009/thats-not-a-memory-leak-its-bloat/
检查机器
也许该机器上运行的其他东西是问题所在。您是否尝试过对机器进行分析 - 例如，运行
top来检查 CPU 使用情况？Check the machine
Maybe other things running on that machine are the problem. Have you tried profiling the machine - for example, running
topto check the CPU usage?