模板
教程
環境
性能
功能
管理
軟件測試之WebLogic Server 性能調優
良好的編程習慣在幫助應用運行方面起了很大的作用，但是僅有它們還是不夠的。應用服務器必須能夠在多種硬件和操作系統之間移植，必須具備通用性以便處理范圍更廣的應用類型。這就是為什么應用服務器都提供了豐富的調試“按鈕”的原因，通過調整這些“按鈕”，能夠使服務器更適合運行環境以及應用程序。
本文針對WebLogic討論了其中的某些調試參數，不過并未將所有可調整的屬性全部列出。此外，在將此處推薦的方法運用到產品環境之前，建議您先在測試環境中對它們測試一番。
性能監控及瓶頸發現
性能調試的第一步是孤立“危險區域”。性能瓶頸可以存在于整個系統的任一部分網絡、數據庫、客戶端或應用服務器。重要的是首先確定哪個系統組件引起了性能問題，調試錯了組件可能會使情況更糟。
WebLogic Server為系統管理員提供了管理控制臺和命令行工具兩種方式監控系統性能。服務器端有叫作mbean的集合，用于搜集諸如線程消耗情況、資源剩余情況、緩存使用情況等信息?？刂婆_和命令行管理器都可以從服務器將這些信息調用出來。圖1的屏幕快照就顯示了EJB容器中緩存的使用和剩余情況，這是控制臺提供的性能監控的選項之一。
代碼分析器也是應用代碼用以探測自身性能瓶頸的另一種有效的工具。有幾個很好的代碼分析器，如:Wily Introscope, Jprobe, Optimizelt。
EJB 容器
EJB容器中最昂貴的操作當然是數據庫調用?D?D裝載和存儲實體bean。容器也因此提供了各種各樣的參數以便減少數據庫的訪問次數。但不管怎樣，除非是在特殊情況下，否則在每個bean的每次交易中，至少都得有一次裝載操作和一次存儲操作。這些特殊情況是:
1. Bean是只讀的。此時，bean只需在第一次訪問時裝載一次，從來不需要存儲操作。當然，如果超出參數read-timeout-seconds的設置，bean將被再次裝載。
2. Bean 有專門的或積極的并發策略，且參數db-is-shared 設置為假。此參數在WebLogic Server 7.0中被重新命名為cache-between-transactions。參數db-is-shared 設置為假相當于參數cache-between-transactions設置為真。
3. Bean在交易中未被修改過，此時，容器會將存儲操作優化掉。
如果不屬于上述任何一種情況，則code path中的每個實體bean在每次交易時，至少會被裝載和存儲一次。有些特征能夠減少數據庫的調用或者降低數據庫調用的開銷，如:高速緩存技術、域(field)分組、并發策略以及緊密關聯緩存(eager relationship caching)等,其中的某些特征是WebLogic Server 7.0新增的。
高速緩存:實體bean緩存空間的大小由weblogic-ejb-jar.xml中的參數max-beans-in-cache定義。容器在交易中第一次裝載bean時是從數據庫調用的，此時bean也被放在緩存中。如果緩存的空間太小，有些bean就被滯留在數據庫中。這樣，如果不考慮前面提到的前兩種特殊情況的話，這些bean在下次調用時就必須重新從數據庫裝載。從緩存調用bean也意味著此時不必調用setEntityContext()。如果bean的關鍵(主)鍵是組合域或者比較復雜，也能省卻設置它們的時間。
域分組:域分組是對于查找方法指定從數據庫加載的域。如果實體bean與一個較大的BLOB域(比方說，一幅圖像)相聯系，且很少被訪問，則可以定義一個將此域排除在外的域組，該域組與一個查找方法相關聯，這樣查找時，BLOB域即不會被裝載。這種特征只對EJB2.0的bean 適用。
并發策略:在WebLogic Server 7.0中，容器提供了四種并發控制機制。它們是獨占式、數據庫式、積極式和只讀式。并發策略與交易進行時的隔離級別緊密相關。并發控制并不是真正意義上的提高性能的措施，它的主要目的是確保實體bean所表示的數據的一致性，該一致性由bean的部署器所強制要求。無論如何，某些控制機制使得容器處理請求的速度比其它的要快一些，但這種快速是以犧牲數據的一致性為代價的。
最嚴格的并發策略是獨占式，利用特殊主鍵對bean的訪問是經過系列化的，因此每次只能有一個交易對bean進行訪問。這雖然在容器內提供了很好的并發控制，但性能受到限制。在交易之間允許互為緩存的時候，這種方法很有用，但在集群環境中不能使用，此時，裝載操作被優化掉，因此可能導致喪失并行性。
原文轉自：http://www.anti-gravitydesign.com
