Rails的過程中花費的時間太長迴應

當我發送AA GET請求，導軌服務器需要花費太長的時間來作出迴應（29分鐘），Rails的過程中花費的時間太長迴應

下面是日誌片段

日誌說，有一個代碼錯誤，沒關係，但爲什麼要花很長時間才能回覆（1723579 ms）我無法找到任何此類行爲的原因。以前，當服務器工作正常時，這個js請求只需要9毫秒的響應時間。但突然間它開始表現得如此。我應該如何調試應用程序以追蹤此類意外行爲的根本原因。

 Started GET "/my-server/jobs/workers?_=1356363515400" for 27*.*.*.* at 2012-12-24 21:08:35 +0530 
    ActionView::Template::Error(): 
      1: <% @jobs.each do |job| %> 
      2: $('#cron_<%= job.id %>').attr('data-content', '<%= distance_of_time_in_words_to_now(job.next_fire_info, true) %>'); 
      3: <% end %> 
      4: 
      5: <% @workers.each do |worker| %> 
      app/models/job.rb:16:in `next_fire_info' 
      app/views/jobs/workers.js.erb:2:in `block in _app_views_jobs_workers_js_erb__101155230_81985760' 
      app/views/jobs/workers.js.erb:1:in `_app_views_jobs_workers_js_erb__101155230_81985760' 


Rendered jobs/workers.js.erb (1718348.7ms) 

Completed 500 Internal Server Error in 1723579ms

我on Rails的3.1.3，紅寶石1.9.3p194， MongoDB的版本V2.2.0，pdfile版本4.5， 32位的Ubuntu（12.04）與2 GB RAM導軌

來源

2012-12-25 suvankar

什麼版本？在3.2.x的某些版本（我認爲3.1.x）中出現了一個錯誤，該錯誤消息在應用程序中意外調用了檢查，這是不必要的，而且非常緩慢 –

我的應用程序包含5個選項卡，其中4個選項卡工作正常，只有在這個「工作」選項卡問題。並且它早期工作正常，但突然引入了這種延遲量。 – suvankar

最後我找到了花這麼長時間回覆的原因。工作人員正在基於cron表達式定期運行。這個特定問題的根源是一個cron表達式錯誤地輸入了工作。這就是爲什麼在執行「distance_of_time_in_words_to_now」時花費了太多時間。

來源

2013-01-02 04:43:32 suvankar

版本3.1.5以前的版本3.1有一個錯誤，當從一個視圖引發一個異常時，rails需要很長時間才能生成異常消息。

如果您不能更新到3.1.5，修復很簡單（見修復它的commit） - 你只需要猴補丁檢查：

module ActionDispatch 
    module Routing 
     module RouteSet 
      alias to_s inspect 
     end 
    end 
end

我以前在轉儲這個一個初始化程序。還有一個寶石（safe_inspect）聲稱爲你做這件事，儘管我從未嘗試過。

來源

2012-12-26 09:35:19

我有類似的問題，它是由身份驗證，所以這只是爲了記錄如果有人在將來有同樣的問題。服務器沒有讓用戶進入，然後重定向到受限制的頁面等。

來源

2014-06-16 13:11:32 gorn

Rails的過程中花費的時間太長迴應

回答

相關問題