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

Question

我的 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.决赛 Facelets 1.1.15 接缝 2.1.2

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

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

更多调试后更新：

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

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

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

我还尝试更改为客户端状态保存，但没有任何运气。没有想法了....希望有人可以提供帮助....

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

Answer 1

根据我的分析，问题是由 facelets 的实现引起的。基于调试器，FaceletViewHandler 类的以下行会导致在每个（甚至 AJAX）请求上重建树（buildBeforeRestore 为 false，因此调用了 buildView 方法）：

        // build view - but not if we're in "buildBeforeRestore"
        // land and we've already got a populated view. Note
        // that this optimizations breaks if there's a "c:if" in
        // the page that toggles as a result of request processing -
        // should that be handled? Or
        // is this optimization simply so minor that it should just
        // be trimmed altogether?
        if (!this.buildBeforeRestore
                || viewToRender.getChildren().isEmpty()) {
            this.buildView(context, viewToRender);
        }

所以在我看来，解决每个请求的树重建问题是深入到 facelets 实现并重新实现......我宁愿重组视图并最大限度地减少组件数量，因此构建树的时间很短。

Answer 2

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

也就是说，恢复视图阶段确实恢复了整个视图，而不仅仅是将要处理或渲染的部分。引用RichFaces taglib documentation：

process：组件的Id['s]（调用UIComponent.findComponent()的格式），在2-5阶段处理，以防由该组件引起的AjaxRequest。可以是单个 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 中的状态丢失。

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

编辑 当我说恢复时，我的意思是ViewHandler.restoreView()，它同时调用了初始获取请求和回发。说restoreView 会简单地重用现有视图是不正确的。例如，JSF 2.0 规范在第 7.6.2.7 节中规定：]

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

所有实现必须：

• 如果无法识别 viewId，则返回 null。
• 调用关联StateManager的restoreView()方法，传递FacesContext实例为 当前请求和计算出的viewId，并返回返回的UIViewRoot，可能是null。

在第 7.7.2 节中：

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

• 客户 -- [...]
• server -- 导致在请求之间将保存的状态存储在服务器上。希望启用的实现 他们保存的状态以故障转移到不同的容器实例时，在实现他们的服务器时必须牢记这一点 侧面国家储蓄策略。默认实现在客户端和服务器模式下序列化视图。在里面 服务器模式，这个序列化的视图存储在会话中，检索视图的唯一键被发送到 客户。通过将序列化视图存储在会话中，可以使用由 容器。

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