默认轨控制器＃动作执行时间可靠和正确吗？

问题描述：

ActiveSupport::Notifications.subscribe 'process_action.action_controller' do |*args| 
    event = ActiveSupport::Notifications::Event.new(*args) 
    puts "Event received: #{event.duration}" 
end

对于这需要137ms的请求，它只显示34ms，但是我在邮递员看到和Pingdom的需要137ms。

那么100ms时间的剩余时间在哪里？

见截图：

报告说，请求了25ms的，但在后期的人花了90毫秒，所以在哪里为65μs的休息去了？

我知道它是因为网络和互联网的速度对于完成渲染也很重要。

我只是想确认这是正确的时间或缺少的东西在这里，例如，如果ApplicationController中有一个过滤器：

before_action :method_name

然后是它考虑的行动“METHOD_NAME”，也或者只是当前操作？

该请求还需要在控制器被调用之前通过Rack，Rack中间件和Rails路由器。中间件也可以在堆栈中的Rails之后注入（例如缓存）。 – max

答

那么100ms时间剩下的时间在哪里？

延迟。请求从邮递员（或pingdom）实例到服务器（并返回）需要时间。 Rails服务器无法知道这些延迟（实际上，它们并不存在），因此它不包含它们。

关于你的截图：

它不包含任何before_action或控制器的这种过滤器。所以如果你的过滤器花费时间，它们将不会被考虑在内。

所以，你应该这样做：

ActiveSupport::Notifications.subscribe 'process_action.action_controller' do |*args| 
    event = ActiveSupport::Notifications::Event.new(*args) 
    puts "Event received: #{event.duration}" 
end

这将包括在过滤器中也花费的时间。

哦，'before_action：method_name'没有提及任何关于操作'method_name'的信息。它适用于所有操作。不知道为什么在这个问题。 –

我的意思是ApplicationController中有过滤器，比如before_action，around_action等等。如果这些操作需要时间，那该怎么办？也许实际的动作需要500毫秒，但before_action需要2分钟，所以总的渲染时间是2.5秒，因此呢？我的意思是屏幕截图中显示的值（即25ms）是否也考虑了各种滤镜？我的意思是包括应用程序控制器的过滤器吗？ – user1735921

@ user1735921：啊，我明白了。我想这个请求时间包括过滤器，是的。但我不是100％确定的。尽管如此，微不足道的检查。在你的一个过滤器中放入一个“sleep（2）'，看看它是如何影响报告时间的。 –

默认轨控制器＃动作执行时间可靠和正确吗？

相关推荐