性能調整指導
提供了一些一般建議以幫助提高性能。性能調整的目的在於降低應用程序服務器處理申請所花費的時間和資源。性能調整讓您的應用程序服務器能夠用更少的時間完成更多的任務。
本章中
改進 Rule Execution Server 性能
您可禁用 Java 2 Security，從而改進 Rule Execution Server 的性能。
改進 Rule Team Server 性能
您可改進體系結構使其符合您的使用要求，從而提高 Rule Team Server 的性能。
改進 Decision Validation Services 性能
您可在不同的計算機上安裝 Rule Execution Server 和 Rule Team Server，從而改進 Decision Validation Services 的性能。
為應用程序提供更多內存
運行 JRules 模塊時，您可能會遇到核心轉儲或 Java 內存不足錯誤。在此列出的過程將幫助解決問題。
|
|
改進 Rule Execution Server 性能
在應用程序的開發階段中，可以執行一些操作來增強規則集的執行性能：
|
開發工件
|
建議
|
|
執行對象模型 (XOM)
|
將執行對象模型 (XOM) 的大小簡化為使用的類。
|
|
規則集執行方式
|
帶有多個算法的規則集比帶有單個算法的規則集耗用更多內存。例如，帶有 RetePlus 與串行或者 RetePlus 與 Fastpath 的規則集比只使用 RetePlus 的規則集耗用更多內存。
|
|
Java XOM
|
在 EAR 中部署的 Java XOM 的大小對解析和執行級別有影響。Java XOM 必須是線程安全的。如果遠程調用 Rule Execution Server，那麼 Java XOM 必須實現可序列化。
|
|
XML XOM
|
使用 XML XOM 的規則集應該配置為在多個同時的執行中運行，方法是配置 XML 文檔驅動程序的池。使用 ruleset.xmlDocumentDriverPool.maxSize 規則集屬性來設置值。缺省值是 1。
|
已開發應用程序並將其部署到應用程序服務器後，存在對性能有影響的若干配置步驟：
|
配置
|
建議
|
|
Rule Execution Server 日誌
|
在生產環境中將日誌級別設置為嚴重或警告。可以在 Rule Execution Server 的資源適配器中 (ra.xml) 訪問該屬性。
|
|
執行單元（XU）
|
應該調節執行單元 (XU) 池大小以均衡會耗用內存的連接數。
|
|
規則會話工廠
|
規則會話工廠應該唯一且在 HTTP 會話之間共享。將在每次創建工廠時執行 JNDI 查找。
|
|
事務
|
如果沒有在引擎級別使用帶狀態的規則會話和事務，那麼在 Rule Execution Server 中停用事務支持，並在 ra.xml 文件中的屬性內設置 NoTransaction 而不是 LocalTransaction。
|
|
類路徑
|
只使用類路徑中最新的規則會話庫。
|
|
垃圾收集器
|
調節 GC 和內存大小。
|
|
規則集更新
|
如果在應用程序中更新規則集，請使用異步解析。在 ra.xml 文件的屬性中提供了該選項。
|
因為 Java 2 Security 相對較新，許多現有的或甚至新的應用可能未準備好應對 Java 2 Security 所能執行的高度嚴格的訪問控制編程模型。如果這些應用尚未準備好應對額外的安全檢查，則管理員應該了解啟用 Java 2 Security 後可能產生的後果。
Java 2 Security 對應用開發人員和管理員提出了一些要求。在您啟用 Java 2 Security 之前，您需要確保所有的應用都獲得了要求的許可權。
|
性能
|
建議
|
|
Java 應用程序
|
啟用 Java 2 Security 後將會降低性能。您可以調整自己的安全配置以最小化它所產生的影響。啟動 Java 2 Security 時請意識到您的應用的性能將受到影響。應用服務器安全模式可集成 Java 2 Security，但這並不是強制的。
如果一個應用尚未做好使用 Java 2 Security 的準備，那麼這個應用很可能導致 Java 2 Security 在運行時發生訪問控制意外並可能出現運行錯誤。
|
|
|
| |
| |
|
|
|
改進 Rule Team Server 性能
Rule Team Server 對 CPU、內存和數據庫資源的消耗非常大。為了確保可擴展性，硬件體系結構應該設置成支持使用需求。Rule Team Server 被設計成可由幾個用戶同時訪問。每次用戶訪問 Rule Team Server URL 時，會在服務器上創建一個 HTTP 會話，並在會話期間填入若干對象，包括當前 IlrSession，用於支持界面中使用的 JSF 組件模型的一些 Java bean，以及一些 Web 組件（Intellirule 編輯器和決策表編輯器）。一個會話需要的內存使用量難以估算，因為它取決於許多因素，包括 GUI 中執行了哪些操作、VM 以及庫的結構。如果同時連接至單個服務器的用戶數量不在單個 VM 所分配的內存範圍內，您應該在一個服務器集群中安裝 Rule Team Server 並使用負載均衡，這樣 HTTP 會話就會按照服務器的可用內存進行分配。
根據使用 Rule Team Server 的用戶數量以及他們經常執行的操作， CPU 的數量也可能是一個極其重要的資源。解析一個 BAL 規則或決策表是一個原子作業，它使詞彙表實例中的一個鎖定被使用。絕大多數的長時間運行操作（規則集生成、報告等等）也消耗大量的 CPU。這意味着，如果許多用戶同時訪問同個項目，瀏覽庫或運行規則集生成、共享的詞彙表等長時間的操作將成為一個瓶頸。這增加了安裝 Rule Team Server 到集群中的需要。
絕大多數的 Rule Team Server 操作執行 SQL 查詢。由於一些查詢可能耗時很長，請考慮將應用服務器和數據庫部署到不同的計算機上，以便推動 Java 計算和數據庫訪問之間的負載分配。這可以改進多用戶連接至庫時的用戶體驗。另外也請將數據源的 JDBC 連接池設置為一個等同於可同時連接至 Rule Team Server 的最大用戶數的數目。如果池太小，當用戶的會話正試圖訪問數據庫時，他們可能會以連接超時告終。
缺省條件下，Rule Team Server 事務超時被設置為 10 分鐘，也就是說，超過規定時間後事務將回滾（操作被中斷）。如果您有一個大型存儲庫並且認為某些操作可能會耗費更多時間，您可以在 Rule Team Server EAR 文件的 web.xml 文件中增加超時值。
下表概述了建議的幾個改進：
|
性能
|
建議
|
|
硬件體系結構和 CPU 使用率
|
設置充足的硬件以支持使用需求。
在服務器集群中安裝 Rule Team Server 並使用負載均衡，這樣 HTTP 會話就會按照服務器的可用內存進行分配。
|
|
數據庫訪問
|
在不同的計算機上安裝應用服務器和數據庫。
請將數據源的 JDBC 連接池設置為一個等同於可同時連接至 Rule Team Server 的最大用戶數的數目。
|
|
事務超時
|
如果用戶在大型存儲庫中執行比較耗時的操作，請在 Rule Team Server EAR 文件的 web.xml 文件中增加超時值。
|
|
|
| |
| |
|
改進 Decision Validation Services 性能
為了改進 Decision Validation Services 的性能，請安裝您用來在不同的計算機上運行測試的 Rule Execution Server 和 Rule Team Server 的實例。這個分離可在 Rule Execution Server 因執行測試套件或模擬操作而消耗資源時，減少對 Rule Team Server 資源（CPU 和內存）的影響。
每次從 Rule Team Server 運行一個測試套件時，就會在 Rule Execution Server 上創建、部署和解析一個新的 RuleApp。這意味着 Rule Execution Server 上的解析消耗無法避免。因此需要專門撥出一個 Rule Execution Server 實例來測試規則。當使用 Decision Validation Services 進行測試和模擬時，不要使用實際執行的 Rule Execution Server。
下表概述了建議的幾個改進：
|
性能
|
建議
|
|
CPU 和內存
|
安裝您用來在不同的計算機上運行測試的 Rule Execution Server 和 Rule Team Server 的實例。
|
|
Rule Execution Server
|
不要在測試和模擬時使用實際執行的 Rule Execution Server。
如果將規則集屬性 ruleset.sequential.trace.enabled 設置為 true，那麼執行規則或任務時，在生成事件期間將增大內存使用率。決策倉庫的性能取決於數據庫。要增強性能，請優化數據庫以處理規則集的具體情況的 CLOB 數據。
生成執行跟蹤將增大內存使用率，因為會高速緩存規則和任務的列表，並會生成規則事件。過濾被跟蹤的對象可以幫助盡量降低與執行跟蹤關聯的性能開銷。如果在跟蹤過濾器 setInfoBoundObjectByRule 設置為 true 時調用執行跟蹤，那麼 toString 方法可能會影響性能。
|
|
XU 池
|
將 XU 池大小設置為低於總可用內存除以規則集最大內存量（在 SSP 的 ra.xml 中設置，或在應用程序服務器的 JCA 連接工廠中加以配置）所得結果。
如果您為虛擬機分配了 1 GB，並且執行的規則集佔據內存的 500 MB，則 XU 池的大小必須低於或等於 2。
|
|
SSP 池
|
將 SSP 池大小設置為 XU 池大小的一半（SSP WAR 的 web.xml 中的 JRULES_JOBS_POOL_SIZE）。
運行測試套件將在 Rule Execution Server 上創建兩個規則集，因此 SSP 池可降低不必要地過載 XU 池的風險，並避免了測試套件或模擬執行中瓶頸的產生。
|
以下文章點擊率最高