JSF 视图在每个 ajax 请求上重建

我的 JSF/RichFaces/Facelets ajax 请求遇到性能问题，据我所知，因为每个 ajax 请求都会重建整个组件树。即使我使用 ajaxSingle=true、在 a4j:region 中包装部分、声明一个用于重新渲染的部分或根本不声明一个部分，也会发生这种情况。我们的页面是一个具有许多嵌套级别的动态页面。该页面可能包含大约 800-900 个字段（inputText、丰富的日历、selectOneMenus 等）。初始加载时间是一个问题，但我理解这个问题，它有很多字段。一旦我们有了初始构建/渲染时间，尽管我们已将所有其他操作设计为 ajax，并且仅重新渲染所需的内容。从 Facelets 调试日志中，我在任何 ajax 调用中都看到类似这样的消息：

2011-08-24 22:19:03,054 DEBUG [facelets.viewhandler] (http-0.0.0.0-8080-2) Took
24445ms to build view: /oconsole/appfile.xhtml
2011-08-24 22:19:09,377 DEBUG [facelets.viewhandler] (http-0.0.0.0-8080-2) Took
6323ms to render view: /oconsole/appfile.xhtml

我不确定我们正在做的事情是否会导致整个组件树的重建，或者 Facelets 是否出于某种原因确定了这种需求（过时的缓存？）。这是我们的堆栈： JBoss 5.1 JSF 1.2 丰富的面孔。 3.3.3.最终 小面 1.1.15 接缝2.1.2

我尝试添加一些上下文参数来查看它们是否有帮助，但它们什么也没做： facelets.BUILD_BEFORE_RESTORE = false facelets.REFRESH_PERIOD = -1 或 5（如 5 分钟）

有没有办法判断我们的视图是否被正确缓存？我们不提供状态保存方法，所以我相信它默认为服务器端。我们所有的请求都发生在长时间运行的对话中。我不确定这是否是一个因素，因为我认为视图会在会话级别缓存？任何帮助将不胜感激，谢谢。

更多调试后更新：

AjaxViewHandler（具有 FaceletsViewHandler 的成员变量）设置了developmentMode=true。我不确定这是否会导致 Facelet 不缓存任何视图，因此任何更改都会在开发周期中刷新......？很难找到有关 Facelets/JSF 视图缓存及其行为和控制的任何信息。此外，当我添加配置参数时：

<context-param>
<param-name>facelets.DEVELOPMENT</param-name>
<param-value>false</param-value>
</context-param>

这个没拿！在调试器中我仍然看到 true 设置。由于我们有很多子视图我也尝试过 com.sun.faces.numberOfLogicalViews 和 com.sun.faces.numberOfViewsInSession 从 15（默认）增加到 1000，这没有效果。

我还尝试更改为客户端状态保存，但没有任何运气。没有想法了……希望有人能帮忙……

似乎 Seam 2.1 自动初始化 RichFaces，我不确定这是否与它有关......

与任何性能问题一样，分析器将极大地帮助定位瓶颈。 （是的，你知道这是restore_view阶段，但不知道restore_view阶段在哪里）。

也就是说，恢复视图阶段确实恢复了整个视图，而不仅仅是将要处理或渲染的部分。引用RichFaces 标签库文档:

process：组件的Id['s]（调用UIComponent.findComponent()的格式），如果该组件引起AjaxRequest，则在第2-5阶段处理。可以是单个 id、以逗号分隔的 id 列表或带有数组或集合的 EL 表达式

RESTORE_VIEW 是阶段 1。另外：

reRender：组件的Id['s]（调用UIComponent.findComponent()的格式），在该组件引起AjaxRequest时渲染。可以是单个 id、以逗号分隔的 id 列表或带有数组或集合的 EL 表达式

此外，我不确定 UIComponent.findComponent() 是使用比组件树更合适的数据结构来实现的。 （在组件树中查找某些内容将归结为线性搜索......）。

我在 JSF 2.0 (Mojarra) 中观察到了类似的效果。我的结论是，视图不得包含超过几十个 UIComponent，无论它们是否被渲染。 （换句话讲，AJAX 不适合页面导航。）我们打算通过仅包含当前在视图中可见的组件来保持视图较小，并在需要出现许多新组件时切换视图。也就是说，我们将拥有 10 个视图，每个视图仅包含一个选项卡的内容，而不是一个视图包含 10 个选项卡，每个选项卡包含 30 个组件。该方法的一个缺点是，切换选项卡时会释放组件，从而导致支持 bean 中未保存的任何状态丢失。

我并不认为这是一个好的解决方案。唉，这是我几周前研究这个问题时发现的最好的一个。我也很高兴能看到更好的。

Edit当我说恢复时，我的意思是ViewHandler.restoreView()，它同时调用初始获取请求和回发。这样说是不正确的restoreView只需按原样重用现有视图即可。例如，JSF 2.0 规范在第 7.6.2.7 节中强制要求：]

The restoreView()方法必须履行以下职责：

所有实施必须：

• 如果无法识别viewId，则返回null.
• 致电restoreView()相关方法StateManager，通过FacesContext实例为 当前请求和计算出的viewId，并返回返回的UIViewRoot，这可能是null.

在第 7.7.2 节中：

JSF 实现支持两种主要的状态保存机制，基于 javax.faces.STATE_SAVING_METHOD 初始化参数（参见第 11.1.3 节“应用程序配置”） 参数”）。该参数的可能值给出了要使用的方法的一般指示，同时允许 JSF 实现在技术细节上进行创新：

• 客户 - [...]
• 服务器——在请求之间将保存的状态存储在服务器上。希望启用的实现 在实现服务器时，必须牢记其保存的状态以故障转移到不同的容器实例 边状态保存策略。默认实现在客户端和服务器模式下序列化视图。在里面 服务器模式，此序列化视图存储在会话中，并且用于检索视图的唯一密钥被发送到 客户。通过将序列化视图存储在会话中，可以使用由会话提供的常用机制来发生故障转移。 容器。

换句话说，JSF 中添加的 AJAX 支持（RichFaces 3 添加到 JSF 1.2 中的支持以及合并到 JSF 2.0 中的支持）旨在减少网络带宽消耗，而不是服务器端 CPU 消耗。