Ruby on Rails開發的五點建議
Ruby on Rails開發使得程序員的工作變得如此簡單，以至于很容易讓人誤以為它能解決一切麻煩，從而沒有給予其后臺情景足夠的注意。程序員要從一開始就把重點放在擴展性上，而不是完全依賴于Rails。
51CTO推薦專題：Ruby on Rails開發教程
事實是，Rails（Java 與Ruby on Rails對接）只能解決80%的擴展工作。而要完成余下20%的Ruby應用程序開發則需要考慮下面的五個注意事項：
1.留意你的數據庫
數據庫查詢，尤其是大量的查詢會造成性能瓶頸。例如，在博客上發表評論，如果你不小心的話，ActiveRecord可能會將每個評論都發出一次查詢。點擊率很高的博客可能會有數以百計的評論，這意味著每個頁面會要執行上百次SQL查詢，顯然這會降低工作效率。
這類問題被稱為“n+1查詢問題”，是我們要避免的。請務必使用合適的“#include”陳述以便獲取查詢中的相關對象。此外，要立刻招引上千個對象。這樣可以實現平衡。
Rails消除了數據庫中繁重的工作但卻不是完全消除。Ruby on Rails開發將程序員與SQL隔離開，但是隨著網站的發展以及應用程序要擴大的需求，你肯定希望能夠手動優化數據庫。要做到這一點，需要明白在里面到底發生了什么。記住在開發模式中記錄登錄情況，確保SQL查詢記錄在了登錄情況中。這樣，當數據庫運行過多查詢或者要介入以提高效率的時候，你就會及時獲知。（Ruby能否成為第二個Java？）
2.解除長期執行的查詢
毫無疑問，我們都希望自己開發出的程序能快速運行。也就是說，使用這些程序的人不會關心程序的背景。如果用戶發出調整個人資料的圖片，視頻編碼等請求，他們不需要在網絡請求發出后等待很久。相反，這些做完以后，發出一個請求，要在后臺等待很久才能返回狀態更新以及獲得頁面的更新。
Rails每次都會發出一個請求，如果長時間運行查詢則會阻止其他請求的執行。盡可能減少網絡請求的工作，并設置一個排隊機制，這樣數據庫就不會超載。這樣可以讓應用程序運行得更快且保持前端網絡服務器的開放狀態。
類似的觀點：許多Ruby on Rails開發的程序都可以處理文件加載和用戶生成的有價值數據。許多這類應用程序都將這類數據保存在Amazon S3上。在嘗試將視頻上傳到應用程序上的同時處理圖像或上傳視頻到Amazon S3可以完全占用前端服務器。這意味著用戶的使用速度會減慢。而是個網絡服務器可以處理許多流量，但是二十個用戶同時上傳多個請求意味著其他人的請求會超時或被拒絕。
底線：為提高效率起見，千萬不要在處理請求的時候進行圖像處理或將文件上傳到另一個服務器上的操作。相反，應該接受上傳，將上傳成功的信息返回給客戶端，然后為其他服務器處理好后臺繁重的工作。
3.使用緩沖技巧來保存應用服務器和數據庫的加載數據
任何時候你都可以緩沖對于計算或數據庫的查詢，即便是只有很短的時間，你也可以擴展整個系統的規模。你可以通過數據庫緩沖服務器控制數據庫服務器的加載數據。數據庫緩沖服務器可以讓你將查詢或計算的對象保存在應用服務器中分布的內存中。
總的格局是當你獲取或計算對象的時候，可以將其保存數據庫緩沖服務器中。那么下次你需要對象的時候，可以首先檢查數據庫緩沖服務器，只有當它不存在的時候，你才會退回到數據庫或重新計算對象，然后將其保存在緩存中。
一個好的程序員要了解各種HTTP協議的各種緩沖功能。使用這些緩沖功能，就可以削減整個堆棧的負荷。
4.監視與測量
監視和測量：服務器，資源使用，應用的性能，頁面響應時長。監測的時候，盡可能地收集信息。如果出現問題，你還擁有信息，性能趨勢和文本。監視工具旨在查出性能上的問題。
如果沒有監測和記錄，你就不能查看系統。如果問題出現的時候，你沒有足夠的數據可以依靠，效率就會減慢。
5.讓方案的執行環境成為產品環境的復制品
許多程序員都在本地開發并測試了應用程序，因而過早部署了產品。隨后他們便會遇到問題，因為真實的產品環境與電腦上的不一樣。
執行和質量保障環境越接近部署環境越好。執行環境不需要很大，但是至少要運行相同規模的軟件。理想情況下，測試應該與產品數據的副本一起運行，這些數據副本要與部署條件類似。這樣做最大的好處是應用程序推送到產品前可以捕捉到錯誤，從而節約我們的時間和精力。
Ruby on Rails開發可以讓我們更快到達端點，讓我們有時間來思考如何擴大應用程序的規模。學習了以上五點以后，很多擴展問題都可以迎刃而解了。
【編輯推薦】
