十分之一的部分突然变慢（随机）
当我查看日志文件时，我得到以下几行：
...
Rendered partials/_something.html.erb (11.8ms)
Rendered partials/_something.html.erb (123.8ms)
Rendered partials/_something.html.erb (8.2ms)
Rendered partials/_something.html.erb (7.3ms)
Rendered partials/_something.html.erb (7.1ms)
Rendered partials/_something.html.erb (8.5ms)
Rendered partials/_something.html.erb (7.2ms)
Rendered partials/_something.html.erb (7.1ms)
Rendered partials/_something.html.erb (7.4ms)
Rendered partials/_something.html.erb (7.9ms)
...
我按照以下方式包含它们，
@collection.each do |something|
render :partial => 'partials/something', :locals => {:something => something}
end
我发现很奇怪的是，在这种情况下，第二次渲染（同一部分）比任何其他渲染花费的时间都要长得多。但是，当我重新加载页面时，其他一些渲染花费了更多时间，而 @collection 变量仍保持相同的顺序。
我实际上不知道如何描述这一点。我的意思是，当同样的某事导致响应缓慢时，我就能弄清楚。但它似乎只是一个随机的。这可能是内存泄漏之类的吗？
我希望你知道答案=）！
When I look at my log-file, I get the following lines:
...
Rendered partials/_something.html.erb (11.8ms)
Rendered partials/_something.html.erb (123.8ms)
Rendered partials/_something.html.erb (8.2ms)
Rendered partials/_something.html.erb (7.3ms)
Rendered partials/_something.html.erb (7.1ms)
Rendered partials/_something.html.erb (8.5ms)
Rendered partials/_something.html.erb (7.2ms)
Rendered partials/_something.html.erb (7.1ms)
Rendered partials/_something.html.erb (7.4ms)
Rendered partials/_something.html.erb (7.9ms)
...
I include them the following way
@collection.each do |something|
render :partial => 'partials/something', :locals => {:something => something}
end
I find it pretty weird that the second render (of the same partial) in this case takes much longer than any other render. However, when I reload the page, some other render is taking much more time, while the @collection-variable is still in the same order.
I actually don't really know how to profile this. I mean, when it's the same something that causes a slow response I'ld be able to figure it out. But it seams to be just a random one. Could this be some memory leak or so?
I hope you know the answer =)!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这可能是垃圾收集。
如果您使用分析软件（如 NewRelic）和 Ruby 解释器（如 Ruby Enterprise Edition (REE)），您可以打开 GC 统计信息并确认这一点，并测量 GC 运行的频率以及您在 GC 上花费的时间。
当您分配更多的对象/数据时，您最终将由于数据大小或分配数量而触发 GC。这看起来几乎是随机的，并且会注入您看到的延迟。
这显示为“损失的时间”，因为您是在 Ruby VM 中测量这一点，而 GC 执行时该 VM 会暂停。因此，您会在应用程序代码库中没有活动的情况下看到这样的随机峰值。
如果您对性能调优或 GC 行为感兴趣，那么可以从 REE 文档的 GC 部分开始：
http://www.rubyenterpriseedition.com/documentation.html#_garbage_collector_and_object_space
This is probably Garbage Collection.
If you use profiling software (like NewRelic) and a ruby interpreter like Ruby Enterprise Edition (REE) you can turn on GC stats and confirm this and measure how often the GC runs and how much of your time is spent in GC.
As you allocate more objects/data, you will eventually trigger a GC due to size of the data or number of allocations. This appears almost random and will inject the delay you see.
This appears as "lost time" because you're measuring this within your Ruby VM, which is paused while GC executes. So you see random spikes like this without activity in the application codebase.
If you're interested in performance tuning or GC behavior, a great place to start is the GC portion of the REE docs:
http://www.rubyenterpriseedition.com/documentation.html#_garbage_collector_and_object_space