WebLogic Server中CMP實體bean的性能調優[9]

　　WebLogic Server中CMP實體bean的性能調優[9]    軟件測試

　　應用程序級緩存

　　如果您的應用程序使用了很多實體bean，那么分析和配置各個bean的緩存會很麻煩。估計從“master-detail”關系的“detail”端返回的bean實例數尤為困難——比如，如果您的應用程序在“訂單”表上執行一個finder操作，每個訂單都有一個“項目”數可變的集合。另一個問題是由于每個實體bean都有一個單獨的緩存，內存沒有得到最有效的利用。認識到“每個bean一個緩存”模型的限制，WebLogic Server(從版本7開始)開始支持實體bean的應用程序級緩存。這使得同一個J2EE應用程序中的多個實體bean共享一個運行時緩存。

　　應用程序級緩存提供了下列好處：它減少了實體bean緩存的數目，從而減少了配置緩存的工作量。 它充分利用了內存和堆空間，因為減少了分段。比如，如果某一特定EJB經歷了一次突發活動，它可以使用聯合緩存中可用的所有內存，而使用該緩存的其他EJB都被換出。如果兩個EJB使用不同的緩存，當一個bean的緩存滿時，容器就不能將EJB換出到另一個bean的緩存中，導致了內存浪費。 它簡化了管理;聯合緩存使系統管理員只需調整單個緩存，而不是很多個緩存。 它提供了更好的可伸縮性。

　　為了定義應用程序級緩存，首先配置weblogic-application.xml中的entity-cache元素。然后在weblogic-ejb-jar.xml中引用entity-descriptor元素中entity-cache-ref元素中的應用程序級緩存。您可以定義一個緩存，然會將其用于應用程序中的所有實體bean，或者為bean組定義不同的緩存。也可以將應用程序級緩存與每個bean一個緩存混合使用，這樣您就有很大的試驗空間。我建議首先從被所有實體bean共享的應用程序級緩存開始，除非您有某些特殊需求。

　　使用應用程序級緩存是為每個bean指定一個緩存的可行的替代方法?？梢脝蝹€緩存的不同實體bean的數目或者已定義緩存的數目沒有限制?？筛鶕ean實例數(與每個bean一個緩存類似的方法)或者最大內存空間來指定緩存大小。從管理角度來看，使用內存的大小很有吸引力，但是要知道WebLogic Server不計算緩存中bean消耗的實際內存數(這可能是一項代價很高的操作);它只是根據weblogic-ejb-jar.xml部署描述符中規定的bean平均大小來分割內存。如果沒有指定大小，則假定每個bean平均有100字節。我認為根據bean實例數指定緩存大小會更透明。

　　選擇哪項策略?

　　本文已經討論了很多內容，但是還未提及可應用于CMP bean的優化技術。比如，CMR緩存和字段組在某些環境下也很有用。選擇最佳并發策略并充分利用長期緩存會給您的應用程序帶來直接的性能提升。由于現在各個WebLogic Server版本中可用的選項有諸多不同(對于其他J2EE服務器也是如此)，所以有時候很難在某一具體情況下做出選擇，尤其是如果開發人員沒有調整這些參數的經驗的話。如果根本沒有指定并發策略和緩存參數，WebLogic Server使用的默認設置從數據一致性方面考慮當然是不錯的選擇，但是從CMP bean的性能方面來看卻不是最佳選擇。沒有放之四海皆準的東西，所以如果您不確定的話，應該分析您的用例，然后利用不同的并發設置進行測試，然后再作出最佳選擇。接著，我會討論一些基本用例以及它們的推薦設置。

　　靜態只讀數據

　　最可能的場景是，當數據庫是靜態(不隨時間變化)、準靜態(變化不頻繁)，或者從應用程序的角度來看可當作靜態或準靜態，并且您的應用程序不修改這些數據時。比如，數據可能被外部進程頻繁更新，但是如果您的應用程序只是每分鐘/小時/天看到這些更新，那么就沒問題。這種情況下，使用帶有適當read-timeout-seconds值的只讀并發策略是合乎邏輯的。如果您的應用程序需要按照某種預定時間間隔看到更新，或者有一個批處理過程來加載數據，而你需要馬上看到新數據，那么就可以像前面描述的那樣，顯式地禁用緩存。比如，您可以在應用程序的正面暴露一個“CMP緩存失效服務”，然后在批處理的最后或者從調度程序中調用。這種情況下緩存大小很容易計算，因為需要該緩存的所有事務共享同一個CMP實例，所以不需要考慮多版本及其對緩存大小的影響。要根據表大小、單個對象大小以及可用內存選擇合理的緩存大小。

原文轉自：http://www.anti-gravitydesign.com