函数 restoreView（JSF 生命周期）中的性能问题答案

【问题标题】：Performance issue in function restoreView (JSF Lifecycle)函数 restoreView（JSF 生命周期）中的性能问题
【发布时间】：2013-03-27 04:20:46
【问题描述】：

我们的应用程序在各个部分都存在渲染时间问题。我们已经能够在 JSF restoreView 阶段（生命周期）中使用分析器（YourKit Java Profiler）查明性能问题。由于我们在某些页面中使用了很多组件，因此树的渲染肯定是问题的根源。 Some question on stackoverflow 看起来很像我们正在处理的事情。此外，我们可以看到开发和生产的速度同样缓慢。

一些规格：

MyFaces 2.1.7
javax.el 2.1.0

Profiler（CTRL+SCROLL 查看详情）：

我们正在努力寻找解决方案。到目前为止，我们想出了这些：

使用更少的组合/组件（这不是很好，因为我们喜欢制作通用组件）。
我们也可以进入 JSF 无状态模式。
找到 JSF 的实际问题（IN DEEP）。
最近发现一些JUEL库（表达式语言）可以大大increase the rendering time。

我一直在处理让 JUEL 与 Spring 3（与 OSGI）一起工作的问题。这是规格： JUEL 2.1.3.1 bundle（注意：此捆绑包使用的 javax.el 版本与我在应用程序中使用的版本不同，这会导致冲突吗？）

我发现了另一个只做Juel Implementation and a more recent version的maven repo。

更新： 找到了 javax.el 冲突的解决方案，因为 juel-api 中存在很多问题（因为它是导出他自己的 javax.el）我用该行修改了清单 Fragment-Host: javax. el 消除它。

是否有实现更好性能的配置/设置？或者，如何使用 MyFaces 和 Spring 实际配置 JUEL？

【问题讨论】：

您能否发布一个产生此问题的 JSF 页面/托管 bean 的基本示例？
您使用哪种 JSF 实现（Mojarra 或 Myfaces）？在响应缓慢期间 CPU 是否大量使用？ JSF 是处于开发模式还是生产模式？（开发模式真的非常慢，因为它在请求期间完成了更多工作才能生成更好的消息）。
@Luiggi Mendoza ：不幸的是，我无法在代码中“精确定位”它，因为它非常大。我会看看如何在较小的规模上重现它。
@Balazs Zsoldos：编辑了我的答案。将发布用于 restoreView 的 CPU 使用分析器输出（大约 50-70%）。
对不起。我之前有一些想法，但没有一个是这里的原因。

标签： performance spring jsf osgi spring-webflow

【解决方案1】：

我会说这个问题是由 Spring Web Flow 引起的。我记得这个问题SWF-1540。首先检查您是否使用了正确的版本（2.4.0.M1 或更高版本）。请注意，我个人没有测试过该配置是否存在性能问题，但我可以说 MyFaces 2.1.7 和更高版本没有任何问题。已知某些 EL 版本存在性能问题，因此请尝试使用 juel 或 apache EL（jasper-el，与 Tomcat 捆绑）。

作为个人意见，请注意 Spring 代理，众所周知，在某些情况下，当页面非常大且复杂时，代理会对性能产生重大影响。建议的解决方案是使用Apache OpenWebbeans，这是一种非常快速的 CDI 实现，针对有大量 bean 互连的情况进行了优化。

您也可以查看这篇文章"Understanding JSF 2 and Wicket: Performance Comparison"，了解有关 MyFaces 性能的提示。

您必须自己尝试适合您的情况，但我希望通过这些建议，您可以更好地专注于搜索。

【讨论】：

我们拥有您提到的所有正确版本。目前，我们正在努力设置 JUEL，我们将其添加到 web.xml（没有错误），但是当页面渲染时，我们可以在控制台中看到：MyFaces Bean Validation support enabled。（这意味着不使用 juel...）
好的。通过将 javax.el 2.1.0 升级到 2.2.4，我们发现了一些有趣的东西。我们注意到一些动作在 4 秒之前和现在大约 300 毫秒之前获得了巨大的性能提升。这是巨大的！试图找到发行说明，以便更好地了解实际更改了什么才能获得这样的性能提升。