標籤：效能最佳化
現象
公司的一個APP點擊某些頁面非常緩慢，有些等待1分鐘，出現大部分使用者不想使用的情況。
目標
要在3天內完成最佳化，越快越好。
解決索引
- 分析：某些跨表查詢沒有建立索引，雖然單表只有30萬資料，但是一關聯查詢，特別是4、5張表關聯時極其緩慢。
- 解決方案：建立索引即可。
緩衝
因為資料都從oracle資料庫讀取，我們首先想到的就是使用緩衝代替。把全部配置表的資料放到Ehcache緩衝中，不直接從oracle讀取，提高效率。
- 為何選用Ehcache？請閱讀《緩衝選型-Ehcache、memcached、Redis》
- 如何使用Ehcache？請閱讀《Ehcache的一個完整例子》
分頁
- 發現有一個頁面查詢需要5秒，比較慢。發現其實結果集是379條詳細記錄，作了379次迴圈全部查出，一次顯示。而實際上使用者不需要一次觀看379條記錄，完全可以採用分頁。APP頁面每頁只顯示了10條，翻頁時再查詢下10條。這樣立馬1秒內能響應。
- 還發現有幾個頁面，查詢條件裡的時間預設是為空白的，那樣子使用者點擊查詢預設就是查詢全部資料，雖然這些頁面作了分頁，但是資料需要排序，把時間最靠前的先顯示，這種情況下如果資料量上了30萬以上，無論索引如何最佳化都是無法做到1秒內完成查詢的。而實際上使用者並不需要查詢所有的資料，只需要把查詢時間預設設定為查詢最近2天，修改後1秒內完成響應。
叢集
目前APP、後端服務都只部署在一個weblogic上，考慮到以後業務發展，使用者數突增，需要考慮weblogic叢集來進行負載平衡。目前主機有256G記憶體，足夠運行，但在近期需完成叢集最佳化防止效能下降再次造成使用者不滿。
總結
上述四種最佳化後，APP基本快速響應，使用者使用還算比較滿意，但其實，最關鍵的還是索引和分頁的最佳化。
- 緩衝的最佳化不是沒有作用，而是太小，oracle的查詢其實已足夠快速。我做了一個實驗，結論是oracle查詢一次16毫秒，第二次同樣的SQL語句是0毫秒，而緩衝也是0毫秒，所以非特殊情況下，基本沒有任何最佳化效果。
- 叢集只是一個預防的措施，因此暫時來看作用不是很突出。
ouyida3的csdn部落格
2015.4.10
APP訪問緩慢最佳化方案
