Rails 中的分析视图

发布于 2024-10-17 09:44:37 字数 115 浏览 5 评论 0原文

我有一个大视图,需要很长时间才能完成渲染内容。分析的最佳方法是什么?视图的哪一部分花费的时间最多?我已阅读有关 ruby​​-prof 的内容,但我不确定将其放入何处以分析视图渲染。如果存在其他选择,我也想了解它们。

I have a big view, which takes very long to finish to render the content. How is the best method to profile, which part of the view is taking the most time ? I have read about ruby-prof, but I'm not sure, where to put in it, to profile the view rendering. If other options exists, I want to know them too.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

水染的天色ゝ 2024-10-24 09:44:37

快速达到瓶颈的最简单方法是使用本地工作的 NewRelics 开发者模式。

  1. 确保您的 Gemfile 中有 ruby-profnewrelic_rpm
  2. 导航到 localhost:3000/newrelic 并开始分析(在右侧栏中)
  3. 向要分析的应用程序页面发出实际请求,可能多次以确保不会测量某些缓存&东西。
  4. 导航回 newrelic 开发者模式,选择请求跟踪。
  5. 按“self”列对表进行排序。这一点至关重要,因为默认按总时间排序会产生误导。
  6. 查看前 10 个调用,了解它们是如何调用的,您可能会发现瓶颈。

免责声明:我已经将这个排序功能推到了newrelic的开发者模式中,所以我有偏见。不过你自己试试吧。

The easiest way to quickly get to bottleneck is using NewRelics Developer mode which works locally.

  1. Make sure you have ruby-prof and newrelic_rpm in your Gemfile.
  2. Navigate to localhost:3000/newrelic and start profiling (in the right bar)
  3. Make an actual request to page of your app you want to profile, possibly multiple times to make sure you don't measure some caching & stuff.
  4. Navigate back to newrelic developer mode, pick request trace.
  5. Sort the table by "self" column. This is crucial since the default sorting by total time is misleading.
  6. Look on top-10 calls, how are they called and you probably find the bottleneck.

Disclaimer: I've pushed this sorting feature to newrelic's developer mode, so I am biased. However try if for yourself.

梦亿 2024-10-24 09:44:37

实际上,这很容易。我刚刚使用 ruby-prof 发现并修复了 HAML 模板的性能问题。模板的相关部分看起来像这样:

  - @collection.each do |x|
    = render :partial => 'name', :locals => {:object => x}

我确保 ruby​​-prof 位于 Gemfile 中,并暂时将其更改为:

  - require 'ruby-prof'
  - RubyProf.start
  - @collection.each do |x|
    = render :partial => 'name', :locals => {:object => x}
  - result = RubyProf.stop
  - printer = RubyProf::CallStackPrinter.new(result)
  - file = File.open('profile.html', 'w')
  - printer.print(file)
  - file.close

然后启动应用程序,点击页面几次,然后打开在我的浏览器中新创建的 profile.html 以查看哪个部分导致了问题。

It's pretty easy, actually. I just found and fixed a performance problem with a HAML template using ruby-prof. The relevant part of the template looked something like:

  - @collection.each do |x|
    = render :partial => 'name', :locals => {:object => x}

I made sure ruby-prof was in the Gemfile and temporarily changed that to:

  - require 'ruby-prof'
  - RubyProf.start
  - @collection.each do |x|
    = render :partial => 'name', :locals => {:object => x}
  - result = RubyProf.stop
  - printer = RubyProf::CallStackPrinter.new(result)
  - file = File.open('profile.html', 'w')
  - printer.print(file)
  - file.close

Then boot up the app, hit the page a couple times, and open up the newly created profile.html in my browser to see which part was causing the problem.

浅语花开 2024-10-24 09:44:37

NewRelic 和日志很有帮助,但有时您需要更多。 NewRelic 确实有一个免费工具可以帮助您在本地进行挖掘,并且像 ruby​​-prof 这样的工具将为您提供信息,但可能很难知道如何使用它。

我在客户的应用程序中发现了一个注册页面,速度慢得离谱,而且没有明显的原因。日志确认它很慢,并且缓慢不是由于数据库造成的,但没有帮助我了解问题所在。

https://github.com/brynary/rack-bug/

比 ruby​​ 更容易使用-prof,当您需要深入研究某些内容时可以快速打开/关闭。我在帮助人们调整 Rails 应用程序时一直使用它。它帮助我了解哪个部分很慢,经过一些尝试和错误,我发现它是注册页面上时区的下拉菜单,

在一个页面上它是(慢速版本):
<%= time_zone_select :user, :time_zone, TZInfo::Country.get("US").zones, {} %>

另一个是:
<%= f.time_zone_select :time_zone, ActiveSupport::TimeZone.us_zones, :default => “太平洋时间(美国和加拿大)”%>

我的前后数字:

orig template render          1392.91
fixed template render         165.56
fixed on REE instead of 1.8.7 100.70

我没有进一步挖掘,因为我还有其他问题需要解决,但可以缓存时区并获得更快的响应。

NewRelic and the logs are helpful, but sometimes you need more. NewRelic does have a free tool that can help you dig locally, and tools like ruby-prof will give you info, but it can be hard to know what to do with it.

I came across a sign up page in a client's app what was ridiculously slow, for no apparent reason. The logs confirmed that it was slow, and that the slowness was not due to the db, but didn't help me see what the issue was.

https://github.com/brynary/rack-bug/

Is easier to use than ruby-prof, and can be turned on/off quickly when you need to dive into something. I use it all the time when helping people tune their Rails apps. It helped me understand which partial was slow, and with a little trial and error, I discovered it was the drop down for timezones on the sign up page

On one page it was (the slow version):
<%= time_zone_select :user, :time_zone, TZInfo::Country.get("US").zones, {} %>

and another was:
<%= f.time_zone_select :time_zone, ActiveSupport::TimeZone.us_zones, :default => "Pacific Time (US & Canada)" %>

My before/after numbers:

orig template render          1392.91
fixed template render         165.56
fixed on REE instead of 1.8.7 100.70

I didn't dig any further, as I had other issues to fix, but it would be possible to cache the timezones and get an even faster response.

岁月流歌 2024-10-24 09:44:37

如果您没有这样做,请先检查应用程序文件夹中的 log 文件夹。它包含应用程序每个环境的日志文件。

为了分析 Rails 应用程序,请将测试放入文件夹 your_app/test/profile

http ://ruby-prof.rubyforge.org/

If you did not do it, check folder log in application folder first. It contains log files for every environment of your app.

In order to profile a rails app, put your tests to folder your_app/test/profile

http://ruby-prof.rubyforge.org/

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文