我正在接近部署基於Rails 3.1.x構建的應用程序，並開始運行一些性能測試。經過一番處理ab之後，我看到一些非常令人沮喪的結果，在Heroku上產生大約15個請求/秒。Rails性能調優的生產？
當我在本地進行測試時，我看到類似的結果，確實表明它是一個應用程序問題。
我正在運行Unicorn，比Thin on Celadon Cedar快上40％。此外，我正在使用PGSQL共享數據庫。
我希望有人能夠分享一份清單或基本上是一張啓動清單，我應該在準備生產應用程序時進行檢查，並轉向對速度進行調整。到目前爲止，我已經而不是找到了一個真正簡潔的可操作項目列表，在我看來，這似乎是有道理的。
或者，如果您在解決這類問題方面擁有紮實的實踐經驗，任何意見都將不勝感激！
我花了一些時間在heroku上調整我的應用程序，並花了一些時間在各種設置中調整Rails應用程序的性能。
當我運行AB -n 300 -c 75 ... myapp.com ....＃這是備用的，以我的主網站，並與麒麟
Requests per second: 132.11 [#/sec] (mean)
Time per request: 567.707 [ms] (mean)
Time per request: 7.569 [ms] (mean, across all concurrent requests)
自由雪松計劃（這是針對沒有做任何事情的主頁，所以我只提供它作爲「heroku能夠以一個非常簡單的頁面在免費計劃上有多快？」的例子，而不是「你的應用程序應該是這個快「）
這裏是我的Rails性能調優101清單：
首先測量瀏覽器/頁面加載時間（瀏覽器提出大量請求，ab只告訴你其中一個請求，通常你的主頁面請求不是問題），從www.webpagetest.org或www.gtmetrix.com面向公衆的頁面，或瀏覽器工具Yslow，谷歌頁面速度或dynatrace專用頁面。如果你看一下頁面加載的瀑布圖（chrome/firefox中的'Net'面板），它通常會顯示你的html快速加載（不到一秒），但其他一切都需要1-3秒才能加載。按照Yslow /頁面速度的建議來改進（確保您完全使用Rails 3.1資產管道內容）
通讀您的日誌文件/新文物以找到'最慢/最頻繁點擊'的請求，並描述該請求發生了什麼（它是緩慢的ruby /大量的內存使用，或大量的查詢？）您需要有一個可靠的方法來檢測和監控性能問題，而不僅僅是改變隨機的東西。一旦你確定了一些目標區域，創建測試腳本以幫助測試之前/之後，並證明你的變化有幫助，並檢測是否有迴歸。
缺乏db列索引是最常見的問題，並且最容易解決。在目標查詢上運行解釋，或查看慢查詢日誌，查看查詢規劃器正在執行的操作。根據需要爲外鍵，搜索列或主數據（覆蓋索引）添加索引。用實際生產數據重新測試以證明它有所作爲。 （你可以在heroku中運行解釋，以及運行缺少或未使用索引的查詢）
大多數性能不佳的Rails應用程序因N + 1查詢而受苦，因爲它很容易編寫order.owner.address.city而不是想想當一個循環中發生了什麼。N + 1查詢不一定是慢速查詢，所以它們不會顯示在慢速查詢日誌中，只是有很多這樣的查詢，並且一次完成所有操作都更有效。使用include或.includes（）來加載該數據，或者以另一種方式查看查詢。
分析您的應用程序的流程並查找緩存機會。如果用戶在索引頁面和詳細信息頁面之間來回跳動，並且可能返回一個詳細信息的ajax視圖，而不離開索引頁面，則會以更快的方式爲他們提供所需的數據。我寫了一些more thoughts about that on my blog
我介紹了這些技術和其他的想法在芝加哥演講在今年的WindyCityRails會議。你可以see the video here on my www.RailsPerformance.com blog 我對heroku的喜愛是你必須從一開始就可以擴展。當您查看郵件列表上的討論時，您會發現大多數人都知道性能最佳實踐，以及如何充分利用服務器。如果你想保持便宜，我也很喜歡你，你會了解到性能調整技巧如何讓你獲得最大的回報。
祝你好運！
因爲還沒有出現，我會提供一個答案，PostgreSQL部分。我無法協助Ruby。
您可以在PostgreSQL wiki上找到優化性能的極好起點。
由於您通常不會在Rails應用程序中編寫SQL查詢，並且（如前所述）服務器設置和硬件在Heroku上不相關，因此您的答案不是很有針對性。 – coreyward
@coreyward：夠公平的。然而，我的答案似乎引起了一些關注，它在目標上產生了更多的答案。 –
感謝提高頭@ErwinBrandstetter！事實上，關於調整Heroku的基於AWS的共享PGSQL數據塊的功能並不多，但是根據其他說明，查詢可能是輪胎問題。 – ylluminate
最綜合的單一答案是使用NewRelic之類的工具來測試你的應用程序並找到慢點。然後，您可以將優化或緩存應用於您的代碼，以消除這些慢點。作爲Heroku客戶，您可以免費獲得NewRelic安裝 - 這是一個可以從Heroku控制檯添加到部署中的插件。
一旦你理解了什麼讓你放慢速度，那麼你可以開始接近它。 Heroku可以處理性能調優的大部分開發工作，所以你不需要在那裏做任何事情。但是，您仍然可以通過優化數據庫查詢並在適當的地方執行片段級和動作級緩存來獲得巨大收益。
謝謝。我稍微使用了NewRelic作爲免費服務，但聽起來好像我現在確實應該考慮其他選項，以便查看吱吱聲的位置在哪裏。謝謝！結果將在這裏回到你身邊。 – ylluminate
有一些相當低掛果樹，幾乎總能取得相當值得的性能提升：
include和join，並確保您使用empty?而不是any?，並儘可能避免使用SELECT，這時您只需要COUNT即可。您需要小心，不要花太多時間優化Ruby例程。除非您正在做大量數據或處理（例如調整圖像大小），否則您可能無法從優化循環或最大限度地減少內存使用量中看到非常顯着的收益。如果您發現某些頁面有問題，請深入查看日誌，並查看這些請求期間發生的情況。
如果您還不是，像HireFireApp這樣的自動縮放應用程序非常適合讓您通過水平擴展來處理大量請求，而無需在慢速時段運行無關的dynos。
PS：有一個新的名爲Blitz的Heroku插件，可以測試多達5,000個用戶的併發負載。
好東西，謝謝你的評論。是的，HireFire是偉大的，邁克爾是一個偉大的人，並認爲他是一個朋友。深入挖掘你的評論，並讓你知道我的結果。其中一些目前不適用，但我對「不優化Ruby例程」表示讚賞，因爲這是我首先考慮的問題之一，但似乎產生了不太好的結果。 – ylluminate
@coreyward，嗨核心，你可以爲簡單的鐵路諮詢？在您的網站上找不到您的聯繫信息。如果是這樣，請發送電子郵件至panabee dot com。謝謝！ – Crashalot
你好，你能看看我有關類似情況的問題嗎？ http://stackoverflow.com/questions/22580297/how-to-tune-a-production-level-heroku-postgres-with-a-ruby-on-rails-application – scaryguy