遇到JSF填充会话的问题。我们的系统在前几天崩溃了。将堆转发给IBM进行审查,结果发现有些会话达到了50M之大。他们发现会话中有一些很大的JSF组件。
那么,是否有任何调整可以进行?有哪些配置项需要查看?还是其他方向。
我们的系统使用JSF和Spring作为表示层,后端使用EJB、Spring和Hibernate,都在WebSphere 6.1上运行。
遇到JSF填充会话的问题。我们的系统在前几天崩溃了。将堆转发给IBM进行审查,结果发现有些会话达到了50M之大。他们发现会话中有一些很大的JSF组件。
那么,是否有任何调整可以进行?有哪些配置项需要查看?还是其他方向。
我们的系统使用JSF和Spring作为表示层,后端使用EJB、Spring和Hibernate,都在WebSphere 6.1上运行。
JSF是一项有用的技术,但您肯定可以用它自毁。
听起来,要么您正在增加视图状态的大小(通过在组件上设置大值),要么您正在将组件的引用泄漏到其他会话状态中(这将是不好的)。另一个潜在的罪魁祸首可能是过大的视图(我看到人们可以轻松构建包含数据表的非常大的控制图形)。我知道IBM提供了丰富的文本和电子表格控件-我无法评论使用它们对状态大小的影响。
最简单的方法是检查 faces-config.xml 中配置为会话范围的托管bean。
JSF在请求之间保存两个东西:
这些被分开,因为某些控件,例如数据表的子级,可以具有多个状态(每行一个)。状态可以保存到表单上的隐藏字段中(如果未加密,则可能是巨大的安全隐患)或会话中。为了适应共享同一会话的多个浏览器窗口(以及在某些实现中的后退按钮支持),多个视图将被存储。
大多数使用IDE构建的JSF应用程序都有后备Bean。通过会话Bean范围,可以将状态保留更长时间,这可能会对会话造成压力。由于每个页面通常只有一个后备Bean,因此您拥有的页面越多,问题就越严重。查看您的faces-config.xml以确定是否存在潜在问题源。
另外,您可以在web.xml中配置HttpSessionAttributeListener。您可以获取堆栈跟踪来帮助识别应用程序中的问题区域。
我曾经在一个JSF项目上工作,发现我们有一个bug,即我们添加了多个JSF h:form元素。这导致每个表单都包含整个视图状态的副本。将每个页面的表单数量减少到1个,可以将页面大小从约2M减少到约300K。
虽然这是一个有点老的话题,但最近我遇到了这个问题。通常,视图和视图状态被存储(如先前提到的),并填充会话以允许后退按钮正常工作。您需要在部署描述符(web.xml)中设置参数来解决此问题。
某些库的多个实例可能需要设置多个参数,例如使用MyFaces和JSF RI时。默认情况下,它们可以设置为相当高的值(分别为20和16)。这意味着您可能会使用应该用于(部分?)会话的20倍空间。
将会话持久性配置到数据库,并使用最少使用算法将最不常用的会话推出内存。它具有高性能(在正确配置的情况下),并将帮助您具体而快速地解决问题。
JSF将视图存储在会话中,以支持其丰富的基于组件的架构(需要维护其视图状态),如果不正确使用,可能会填满堆。如果没有大型工作流程,请始终选择每个会话中的较少视图数量。同时尽量避免将Backing Bean存储在会话中。使用自定义标签仅为下一个请求周期创建数据对象。如果应用程序中有长工作流程,则可以使用JSF与Spring Web Flow结合使用,引入视图范围和流程范围,以减少在会话中配置的视图数量。JSF可用于轻松构建丰富的用户界面,帮助构建类似桌面应用程序的Web应用程序。为JSF框架分配特定的堆空间来完成其工作。但是,在应用程序端要高效利用内存,并确保没有内存泄漏。所有的内存泄漏都需要在开发过程中进行调查和纠正。始终使用分析器来查找应用程序中存在的内存泄漏和性能瓶颈。
Mat.
你可能会遇到许多后备Bean作为会话范围的问题。
你可以尝试研究MyFaces Orchestra。这是一个提供对话范围的库,因此一旦用户完成了特定的Bean集合,它们将从会话中删除。
我知道Spring WebFlow也有类似的功能,但我还没有真正研究过它!