JSF 調整

Question

遇到 JSF 正在填滿我們的會話的問題。 前幾天我們發生了系統崩潰。 將 Heap 發送給 IBM 進行審核，發現我們有一些會話高達 50M。 他們在 session 中發現了 JSF 和一些非常大的組件。

那么，有沒有可以做的調優呢？ 配置項要看？ 或者其他方向。

Our system is build using JSF and Spring for the presentation layer, the back end is EJB, Spring and Hibernate all running on WebSphere 6.1.

Answer 1

JSF 是一項有用的技術，但您當然可以用它來吊死自己。

聽起來，要么您正在誇大視圖 state 的大小（通過在組件上設置較大的值），要么您正在將對組件的引用泄漏到其他 session Z9ED39E2EA931586B6A3385A6942EF7 另一個潛在的罪魁禍首是視圖過大（我已經看到人們可以輕松構建 UI 樹導致非常大的控制圖，其中到處都是數據表）。 我知道 IBM 提供富文本和電子表格控件 - 我無法評論使用這些控件會對 state 大小產生什么影響。

最容易實現的是檢查faces-config.xml中為 session scope 配置的托管 bean。

JSF 在請求之間保存了兩件事：

• 視圖（頁面上的所有控件）
• 視圖 state（控件的 state）

這些是分開的，因為某些控件（例如數據表的子項）可以具有多種狀態（每行一個狀態）。 State 可以保存到表單上的隱藏字段（如果未加密，可能是一個很大的安全隱患）或 session。 為了適應多個瀏覽器 windows 共享相同的 session（並且在某些實現中，后退按鈕支持），存儲多個視圖。

• 應該有一個配置選項來設置應用程序將在任何給定時間為給定用戶保留在 session 中的視圖狀態數。
• 您可以通過提供一個測量已保存視圖/狀態大小的StateManager來測量視圖 state 的大小（在 faces-config.xml 中配置一個 StateManager，並使用一個采用 StateManager 的公共構造函數 - 請參閱Z798476CFD7034D66243更多詳細信息state 是可序列化的，您可以通過將其轉儲到流中來檢查其大小）。

大多數 IDE 構建的 JSF 應用程序都有支持 bean。 It would be possible, via session bean scope to hold onto state longer than you want, placing a strain on the session. 由於每頁往往有一個支持 bean，因此您擁有的頁面越多，問題就越大。 檢查您的faces-config.xml看看這是否是潛在的問題來源。

您可以做的其他事情是在您的web.xml中配置一個HttpSessionAttributeListener 。 您可以獲得堆棧跟蹤以幫助識別應用程序中的問題區域。

Answer 2

這是我聽說的第二個因 JSF 和過多的 object 創建而死亡的系統。 另一台也在后端使用了Spring和Hibernate。 使用 OptimizeIt 進行分析表明，所有請求的后端響應都在毫秒級，但是您可以使用秒表再次為瀏覽器渲染計時，因為它花了很長時間 - 30 秒到幾分鍾。 客戶端消耗的 Memory 太荒謬了。

我只是一個觀察者，不是那個項目團隊的成員。 我將不得不詢問問題是否已解決，如果是，解決方案可能是什么。

但是，如果兩點形成趨勢，我會說 JSF 可能存在致命缺陷。 就個人而言，我完全遠離它。

為什么不試試 Spring web 前端看看是否有幫助？ 如果您遵循 Spring 習慣用法，則將 JSF 替換為基於 JSTL 的 JSP 和 Spring 控制器應該是一個相對簡單的問題。

Answer 3

我正在研究 JSF 項目，發現我們有一個錯誤，我們正在添加多個 JSF h:form 元素。 導致每個表單都包含整個視圖狀態的副本。 將每頁減少到 1 個表單將頁面從 ~2M 減少到 ~300K。

Answer 4

配置 session 持久化到數據庫，它將使用最少使用算法將最少使用的會話推出 memory。 它具有高性能（如果配置正確），將具體而快速地幫助您。

Answer 5

JSF 生產環境調優技巧：
- The usage of images, CSS, and JavaScript resources should be done by standard HTML tags (img,link,script) not server-side, and be sure to set #{request.contextPath} before the url to avoid relative paths issues.
- 使用omnifaces cache頁面的static部分(menu,header,footer)
- 將refresh-period變量設置為 -1
- 將project-stage設置為生產
- 檢查您的代碼過濾器（如果有）

另外，請查看我在 DZone 上的文章“ Java Server Faces in Real-Life Applications ”，它將為您提供有關 JSF 在開發、測試和生產環境中的全貌。

Answer 6

有點老話題，但最近遇到了這個。 通常，視圖和視圖 State 被存儲（如前所述），並填滿 session 以允許后退按鈕工作。 在需要設置的部署描述符 (web.xml) 中有一些參數可以對其進行排序。

某些庫的多個實例可能需要多個參數設置，例如在使用 MyFaces 和 JSF RI 時。 默認情況下，它們可以設置為一些相當高的值（我相信分別為 20 和 16）。 這意味着您可以為 session （部分？）使用 20 倍的空間。

Answer 7

您可能會遇到許多支持 bean 的問題，例如 session scope。

您可以嘗試查看MyFaces Orchestra 。 這是一個提供對話 scope 的庫，因此一旦用戶完成了一組特定的 bean，他們將從 session 中刪除。

我知道 Spring WebFlow 具有類似的功能，但我還沒有真正研究過！

Answer 8

JSF 將視圖存儲在 session 中，以支持其豐富的基於組件的架構（需要維護其視圖狀態），如果使用不當，可能會填滿堆。 如果您沒有大的工作流程，請始終使用 go，每個 session 的視圖數量很少。 還要盡可能避免將 backingbeans 保留在 session 中。 使用自定義標簽使數據 object 僅用於下一個請求周期。 We can also use Spring Web Flow with JSF, which introduces view scope and flow scope if we have long workflows in application to reduce the no of views configured in session. JSF可用於輕松制作豐富的用戶界面，有助於構建類似於桌面應用程序的Web應用程序。 為 JSF 框架分配一個特定的堆來完成它的工作。 但是在應用程序端有效地使用 memory 並確保沒有 memory 泄漏。 所有 memory 泄漏都需要在開發過程中進行調查和糾正。 Aways 使用分析器來查找應用程序中存在的 memory 泄漏和性能瓶頸。

墊。

Answer 9

如果您使用的是 MyFaces < 1.1.6，則在 session 中緩存舊序列化視圖的方式中存在巨大的 memory 泄漏，實際上永遠不會讓它們釋放，以便它們可以被垃圾收集。 我對此有一個嚴重的問題，並且也有 50Mb 的會話。 MyFaces 的快速升級解決了這個問題，沒有任何問題。