RESTORE_VIEW 和 RENDER_RESPONSE 耗时过长答案

【问题标题】：RESTORE_VIEW and RENDER_RESPONSE take too longRESTORE_VIEW 和 RENDER_RESPONSE 耗时过长
【发布时间】：2014-03-28 10:16:54
【问题描述】：

我正在开发一个 JSF 2 应用程序（primefaces 3.4.1 和 Mojarra 2.1.10）。视图很大，因此应用程序响应速度不是很快，但仍然可以接受。当用户在表单中显示新数据时，这不是问题。但是当他只是编辑数据时，就更烦人了。

在离开某些字段时，我们执行了一些简单的逻辑（使用 ajax）：

<p:ajax 
        event="blur" 
        process="@this" 
        listener="#{myBean.myMethod()}" 
        partialSubmit="true"
        update="another_component_id" />

不出所料，当我用chrome开发者工具查看请求/响应的内容时，可以看到只发送了文本字段，只收到了“更新”中引用的组件。
我希望它会很快，但是 RESTORE_VIEW 和 RENDER_RESPONSE 阶段各需要大约 3-4 秒。
如果我删除 partialSubmit 并设置 update="@form"，则会交换更多数据，但这两个阶段仍然需要相同的时间。

查看此链接时： http://www.industrieit.com/blog/2011/11/stateless-jsf-high-performance-zero-per-request-memory-overhead/ 我读过： “页面性能在很大程度上与视图树的大小有关，无论它的大部分是否由于位于未渲染的分支中而被排除在渲染之外。”。这似乎证实了我的观察，但我没有找到太多关于此的信息。

我说的对吗？即使只提交/更新部分页面，RESTORE_VIEW 和 RENDER_RESPONSE 仍然很长，这是否正常？

提前致谢。

【问题讨论】：

大有多大？您的 JSF 代码的大小是多少，使用了多大的包含？您在视图范围的 bean 中存储了多少数据？视图范围的 bean 是否序列化（服务器/客户端）？
STATE_SAVING_METHOD 是服务器。 Facelets 可能包含，我无法评估 jsf 代码大小。 Facelets 是通用的，带有依赖于支持 bean 的循环。 html 是 150 ko。它主要是 primefaces 数据表和文本字段。该视图包含 250 个 UIComponent 对象。没有视图范围的 bean，大多数是会话范围的。我不知道会话大小。我认为它不会被序列化，即使在服务器上也是如此。有些对象是不可序列化的，所以我认为如果服务器曾经尝试序列化会话，我会得到错误。同时用户很少（可能 5 个）。

标签： jsf-2 primefaces

【解决方案1】：

大多数时候，性能问题来自数据库和业务层，所以首先要看看那部分。现在，与新的实现相比，JSF 1.2 已经过时了，从那时起发生了很多事情。 JSF 2 的重大改进（例如部分状态保存）解决了大部分性能瓶颈。

看看这篇文章，它将阐明您关于性能的问题Understanding JSF 2.0 Performance – Part 3 on JSFCentral。代码在Web Framework Performance Comparison GitHub Repo，所以你可以看一下代码，自己看看问题出在哪里。我个人根据自己的优点推荐Apache MyFaces。与 Spring MVC 等面向动作的 Web 框架相比，MyFaces 做得非常好，这一点毋庸置疑。

如果您想要极致性能，MyFaces 2.2 中捆绑了一个视图池实现，您可以尝试，但第三方库需要与之兼容。

【讨论】：

谢谢。但最初的问题确实集中在这样一个事实，即只处理一个字段似乎与处理整个页面一样多。
这取决于组件库的实现，我想这是因为您使用的是非常旧的东西，但 JSF 2 不应该发生这种情况。在 Mojarra 的某些版本中检测到了一些问题@ 987654324@，没有文章说的那么戏剧化，但问题很大，因为它以指数方式减少了时间。它已在最新版本的 Mojarra 中得到修复。
我的错，我使用的是 Mojarra 2.1.10（所以 JSF 2）。我刚刚更新了 OP