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