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 的快速升级解决了这个问题，没有任何问题。