ruby-on-rails – 为什么ActionDispatch :: Routing :: RouteSet需要这么长时间

前端之家收集整理的这篇文章主要介绍了ruby-on-rails – 为什么ActionDispatch :: Routing :: RouteSet需要这么长时间前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我在Rails 4.2.1上使用Grape为我们的应用程序提供API.

但是当我今天检查Newrelic的性能时,我发现RackApp Proc#call和Grape API :: Root#call占用了大量的时间. (见截图)

然后我尝试使用rack_timer记录中间件中消耗的时间,发现ActionDispatch :: Routing :: RouteSet占用了大部分时间:

Rack Timer (Application Action) -- ActionDispatch::Routing::RouteSet: 67.12579727172852 ms
Rack Timer (Application Action) -- ActionDispatch::Routing::RouteSet: 101.51457786560059 ms
Rack Timer (Application Action) -- ActionDispatch::Routing::RouteSet: 84.18059349060059 ms
Rack Timer (Application Action) -- ActionDispatch::Routing::RouteSet: 1236.2565994262695 ms
Rack Timer (Application Action) -- ActionDispatch::Routing::RouteSet: 8.124351501464844 ms
Rack Timer (Application Action) -- ActionDispatch::Routing::RouteSet: 55.65309524536133 ms

甚至在ActionDispatch :: Routing :: RouteSet中需要500ms – 1000ms的情况.我怎么能找到这个问题,怎么知道我在Rails路线上做错了什么?

非常感谢您的帮助.

解决方法

对我来说,事实证明Newrelic ruby​​代理不能与我用来构建API端点的gem_pants一起使用.

有一个第三方gem’rocket_pants-rpm’来解决这个问题,但最初的一个停止使用newrelic_rpm版本3.9来解决问题,尝试在https://github.com/SpartaSales/rocket_pants-rpm使用分叉版本

这是添加此gem后newrelic报告查找的方式.

newrelic request time percentage

猜你在找的Ruby相关文章