Sunday February 11, 2007
最近火速看盤經歷一陣連續的大改版, 主因是 DB 越來越慢了, 解決方式是從 Hibernate 著手, 看看有沒有加強的空間..
速記下幾個最近才知道的事情, 供大家參考:
Statistics & Criteria
要做 tuning, 之前都是看資料庫的 slow queries 來挑, 雖然也是 ok, 但隨著 query 越來越多, 要從 db queries 去反推回是哪個 HQL/Criteria 還滿困難的..
另外也沒有辦法得到物件的存取資訊等, 在做 cache 時的判斷也很麻煩..
直到最近加入 Hibernate Statistics 的管理頁面, 才知道早該做這個功能..
要用 Hibernate Statistics 很簡單, 呼叫 sessionFactory.getStatistics() 就好了..
可以印出 Hibernate Entities, Collections, Queries 的使用次數與各種資訊..
我大概都看看呼叫次數與平均時間, 再依物件特性就可以決定是否需要使用 2nd level caches 或 query caches, 很方便..
不過因為要看 Hibernate Statistics, 也暴露了 Criteria 的一個嚴重缺點, 就是印不出 Criteria 的 query caches, 因為 Criteria 沒有文字的敘述..
Criteria 雖然可以加上 comment, 但也是大工程..
所以, 只好忍痛將所有 Criteria 改為 HQL, 這也就是會花這麼多時間的原因..
若你剛接觸 Hibernate, 建議你就不要考慮 Criteria 了..
雖然還滿高興自己總是能用 Criteria 兜出頗難的 query, 但, 為了未來監控, 還是改用 HQL 吧~~
Caches
雖然 Gavin King 說 Query Cache 沒啥用, 但我覺得怎麼會呢?
看到 Queries 數狂降, 也是心中一股 "早知道, 我就..."
至於 Cache 的選用..
因為我們的資料庫存取不僅是網域內, 也有可能是其他網路上的電腦, 所以使用 JbossCache 相當麻煩..
只好退一步, 選用 EHCache, 但相對的, 僅能 Cache "非常不常更新或不更新的資料"..
但對我的系統幫助也夠大了..
至於 Cache 怎麼設定, 我建議大家做幾個 Test Cases, 實際看看資料有沒有被 cache 起來..
因為實際上跟想的都有點些差距, 需要動手做看看比較清楚..
詳細的設定細節, 或許下次 JUG 再跟大家分享囉~~
Connection Pool
有些 Connection Pool 可能有提供狀態監控 (我是用 c3p0), 就可以順便監控即時的 DB 連線數..
前面提的監控網頁也可以加上這個, 我覺得很實用..
我之前一直滿困惑, 不知道 DB Connection 上限該設多少 (最後決定設 64 或 92)..
透過這個就可以正確的做個決定..
另外, 根據之前做壓力測試的心得, 雖然 c3p0 不是什麼太正式的 Connection Pool, 但是我測試的結果, 只有 c3p0 在 Connection 數到上限時不是直接丟 Exception, 而會有 wait for next available 的機制, 這個很重要..
Many to Many
雖然我知道這不可避免, 但使用 Many to Many, 對資料庫的複雜度都是個提升, 尤其是透過 hibernate 幫你產生 queries, 很可能會不經意產生讓你很吐血的 table join..
若您有使用 Many to Many 的關係, 建議你特別注意一下產生出來的 queries 效能..
Filter
Filter 跟上面一樣, 也是有可能會不按牌理出牌幫你 join, 請特別注意一下產生的 queries..
Transactions
我不知道曾經在哪裡讀到, 加 transaction 不會為系統增加多少負擔..
因為一直對 DB 這類東西沒啥興趣, 所以就照做, 不該加的地方也加了..
最近印出很多數據, 才發現 ... 涉世未深的我被騙了..
若是有大量 Queries, 看看有沒有辦法把 Queries 與 insert/update 做某種程度的分開吧..
tags: java hibernate
Feb 11 2007, 01:38:04 AM CST Permalink Comments [41]
