JSF 调优
遇到 JSF 填满我们的会话的问题。 前几天我们发生了系统崩溃。 将Heap发送给IBM进行审查，发现我们有一些会话高达50M。 他们在会话中发现 JSF 组件，有些非常大。
那么，有什么可以调整的地方吗？ 配置项要看什么？ 或者其他方向。
我们的系统是使用 JSF 和 Spring 作为表示层构建的，后端是 EJB、Spring 和 Hibernate，全部运行在 WebSphere 6.1 上。
Running into an issue where JSF is filling up our sessions. We had a system crash the other day. Sent the Heap to IBM for review and found that we had some sessions as large as 50M. They found JSF components in the session and some very large.
So, is there any tuning that can be done? Configuration items to look at? Or other direction.
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
JSF 是一项有用的技术，但您肯定会被它搞得一团糟。
听起来，要么您正在夸大视图状态的大小（通过在组件上设置较大的值），要么将对组件的引用泄漏到其他会话状态中（这会很糟糕）。 另一个潜在的罪魁祸首是过大的视图（我已经看到人们可以轻松构建 UI 树，从而导致非常大的控制图，其中到处都有数据表）。 我知道 IBM 提供了富文本和电子表格控件 - 我无法评论这些控件的使用会对状态大小产生什么影响。
最容易实现的目标是检查在faces-config.xml 中为会话范围配置的托管bean。
JSF 在请求之间保存两件事：
这些是分开的，因为某些控件（例如数据表的子控件）可以有多个状态（每个控件一个状态）排）。 状态可以保存到表单上的隐藏字段（如果未加密，可能会造成很大的安全隐患）或会话中。 为了适应共享同一会话的多个浏览器窗口（并且在某些实现中，支持后退按钮），存储了多个视图。
大多数 IDE 构建的 JSF 应用程序都有支持 bean。 通过会话 bean 作用域，保持状态的时间可能会比您想要的更长，从而给会话带来压力。 由于每页往往有一个支持 bean，因此页面越多，问题就越大。 检查您的faces-config.xml，看看这是否是潜在的问题根源。
您还可以做的其他事情是配置 HttpSessionAttributeListener 在您的 web.xml 中。 您可以获得堆栈跟踪 帮助识别应用程序中的问题区域。
JSF is a useful technology, but you can certainly hang yourself with it.
It sounds like, either you're inflating the size of the view state (by setting large values on components) or you're leaking references to components into other session state (which would be bad). Another potential culprit would be an excessively large view (I've seen the ease with which people can build UI trees lead to very big control graphs with data tables everywhere). I know that IBM provides rich text and spreadsheet controls - I can't comment on what effect the use of these will have on state size.
The low hanging fruit is to check the managed beans configured for session scope in faces-config.xml.
JSF saves two things between requests:
These are separated because some controls, such as children of a data table, can have multiple states (one for each row). State can be saved to either a hidden field on the form (which, if unencrypted, can be a big security hazard) or in the session. In order to accommodate multiple browser windows sharing the same session (and, in some implementations, back button support), multiple views are stored.
Most IDE-built JSF apps have backing beans. It would be possible, via session bean scope to hold onto state longer than you want, placing a strain on the session. Since there tends to be one backing bean per page, the more pages you have, the bigger the problem will be. Check your faces-config.xml to see if this is a potential source of problems.
Something else you could do would be to configure a HttpSessionAttributeListener in your web.xml. You can get a stack trace to help identify problem areas in your app.
这是我听说的第二个因 JSF 和过多的对象创建而死亡的系统。 另一种在后端也使用了Spring和Hibernate。 使用 OptimizeIt 进行分析表明，所有请求的后端响应都是毫秒级的，但是您可以使用秒表再次对浏览器渲染进行计时，因为它花费了很长时间 - 30 秒到几分钟。 客户端消耗的内存是荒谬的。
我只是一个观察者，不是该项目团队的成员。 我必须询问问题是否已解决，如果是，解决方案可能是什么。
但如果两点构成一个趋势，我会说 JSF 可能存在致命缺陷。 就我个人而言，我完全远离它。
为什么不尝试一下 Spring Web 前端，看看是否有帮助呢？ 如果您遵循 Spring 习惯用法，那么用基于 JSTL 的 JSP 和 Spring 控制器替换 JSF 应该是一件相对简单的事情。
This is the second system I've heard of that has died because of JSF and excessive object creation. The other one also used Spring and Hibernate in the back end. Profiling with OptimizeIt showed that the backend response was on the order of milliseconds for all requests, but you could time the browser rendering again with stopwatch because it took so long - 30 seconds up to several minutes. Memory consumed by the client was ridiculous.
I was only an observer, not a member of that project team. I'll have to ask if the problem was ever fixed and, if so, what the solution might have been.
But if two points make a trend, I'd say that JSF might be fatally flawed. Personally, I stay away from it completely.
Why not try a Spring web front end and see if that helps? If you follow the Spring idiom, it should be a relatively simple matter of replacing JSF with JSTL-based JSPs and Spring controllers.
我当时正在开发一个 JSF 项目，发现我们在添加多个 JSF h:form 元素时遇到了一个错误。 导致每个表单中都包含整个视图状态的副本。 减少到每页 1 个表格，将页面从约 2M 减少到约 300K。
I was working on a JSF project and found that we had a bug where we were adding multiple JSF h:form elements. Resulting in a copy of the entire viewstate being included with every form. Cutting down to 1 form per page shaved the pages from ~2M down to ~300K.
您可能会遇到使用大量支持 bean 作为会话范围的问题。
您可以尝试查看 MyFaces Orchestra。 这是一个提供会话范围的库，因此一旦用户完成了一组特定的 bean，它们就会从会话中删除。
我知道 Spring WebFlow 有类似的功能，但我还没有真正研究过它！
You might be running into issues with lots of backing beans as session scope.
You could try looking into MyFaces Orchestra. This is a library which provides a conversation scope, so once a user has finished with a particular set of beans they will be removed from the session.
I understand that Spring WebFlow has similar features but I haven't really looked into it!
JSF 在会话中存储视图以支持其丰富的基于组件的架构
（需要维护其视图状态）并且如果使用不当可能会填满堆。 如果您没有大的工作流程，请始终保持每次会话的浏览量较小。 还要尽可能避免将 backingbeans 保留在会话中。 使用自定义标签使数据对象仅用于下一个请求周期。 我们还可以将 Spring Web Flow 与 JSF 结合使用，如果我们在应用程序中有很长的工作流程，它会引入视图范围和流范围，以减少会话中配置的视图数量。 JSF 可用于轻松创建丰富的用户界面，这有助于构建类似于桌面应用程序的 Web 应用程序。 为 JSF 框架分配一个特定的堆来完成其工作。 但在应用程序端要有效地使用内存并确保不存在内存泄漏。 所有内存泄漏都需要在开发过程中进行调查和纠正。 总是使用探查器来查找应用程序中存在的内存泄漏和性能瓶颈。
垫。
JSF stores the views in session to support it's rich component based architecture
(need to maintain its view state) and may fill the heap if not used properly. If you do not have big work flows, always go with small no of views per session. Also avoid keeping backingbeans in session as much as possible. Use custom tag to make the data object just for the next request cycle. 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 can be used for making rich user interface easily, that helps to build Webapplication similar to desktop application. Allot a specific heap to JSF framework to do its work. But use the memory efficiently in the application side and make sure that there is no memory leakage. All memory leaks need to be investigated and corrected during the development itself. Aways use a profiler to find memory leaks and performance bottlenecks that exists in the application.
Mat.
如果您使用的是 MyFaces < 1.1.6 它在会话中缓存旧的序列化视图的方式存在巨大的内存泄漏，实际上永远不会让它们释放，以便它们可以被垃圾收集。 我遇到了一个严重的问题，并且也有 50Mb 的会话。 MyFaces 的快速升级解决了该问题，没有出现任何问题。
If you are using MyFaces < 1.1.6 there is a huge memory leak in the way it caches old serialized views in the session effectively never letting them release so that they can be garbage collected. I had a serious problem with that and had 50Mb sessions as well. A quick upgrade of MyFaces rectified the problem without any problems.
将会话持久化配置到数据库，它将使用最少使用的算法将最少使用的会话挤出内存。 它具有高性能（如果配置正确），并将为您提供具体而快速的帮助。
Configure session persistense to database, and it will use least-used algorithm to push least used sessions out of memory. It has high performance (when configured properly) and will help you concretically and fast.
这是一个老话题了，但最近才遇到这个问题。 通常，视图和视图状态会被存储（如前所述），并填充会话以允许后退按钮工作。 部署描述符 (web.xml) 中需要设置一些参数来对此进行排序。
某些库的多个实例可能需要多个参数设置，例如在使用 MyFaces 和 JSF RI 时。
默认情况下，它们可以设置为一些相当高的值（我认为分别为 20 和 16）。 这意味着您可以使用 20 倍于会话（部分？）的空间。
Bit of an old topic, but came across this recently. Often, the View and View State are stored (as previously mentioned), and fills up the session to allow the back button to work. There are parameters to sort this in your deployment descriptors (web.xml) that need to be set.
Multiple instances of certain libraries may need more than one parameter setting, such as when using MyFaces and JSF RI.
By default, they can be set to some pretty high values (20 and 16 I believe, respectively). This means that you can be using 20 times the space you should be for (parts of?) the session.
生产环境的 JSF 调优技巧：
- 图像、CSS 和 JavaScript 资源的使用应通过标准 HTML 标签
(img,link,script)而不是服务器端来完成，并且一定要设置#{request.contextPath }在 url 之前以避免相对路径问题。- 使用
omnifaces缓存缓存页面的静态部分（菜单、页眉、页脚）- 将
refresh-period变量设置为-1- 将
项目阶段设置为生产- 检查您的代码过滤器（如果有）
另外，请查看我的文章“Java Server DZone 上的“现实生活应用程序中的面孔”，它将为您全面介绍 JSF 在开发、测试和生产环境中的情况。
JSF tuning tips for production environment:
- 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.- Cache static sections of the page
(menu,header,footer)usingomnifaces cache- Set
refresh-periodvariable to -1- set
project-stageto Production- Review your code filters if any
Also , Check my article "Java Server Faces in Real-Life Applications" on DZone, it will give you the full picture about JSF in development,test and production environments.