Struts 2 OGNL s:iterator vs JSTL c:forEach 性能答案

【问题标题】：Struts 2 OGNL s:iterator vs JSTL c:forEach performanceStruts 2 OGNL s:iterator vs JSTL c:forEach 性能
【发布时间】：2011-11-17 11:29:38
【问题描述】：

我最近一直在构建一些相当动态的 Web 应用程序，这些应用程序严重依赖数据库 (JPA) 支持的配置。这些应用程序是多用户、多帐户系统，最终用户可以在其中基于 JPA 实体创建自定义表单。

我注意到随着我的 JSP 页面变得越来越复杂，我的性能和加载时间受到了影响。最初我认为是数据层导致了我的瓶颈，但今天我一时兴起替换了几个包含页面，这些页面是使用基于 JSTL 的迭代方案的 struts 迭代的对象列表动态创建的。我的页面加载时间从大约 10 秒变为大约 1 秒，这让我大吃一惊。随着列表大小的增加，JSP 页面的呈现时间会显着增加（使用 struts2 OGNL 迭代）。

在我的 struts 配置中，我关闭了开发模式，我使用的是一个简单的主题集，没什么特别的。我正在考虑重写我的一些迭代繁重的页面以使用 JSTL 而不是 struts，但我想我会四处询问，看看我是否遗漏了什么，或者是否有人遇到过类似的情况。

【问题讨论】：

标签： jsp struts2 jstl ognl

【解决方案1】：

OGNL 很慢；较新的版本将寻求一些性能增强。

S2 和 JSTL 标记功能重叠的 IMO，与 S1 一样，我倾向于 JSTL。

如果不知道更多关于你的实际表示层，你已经对increase performance采取了哪些措施，或者关于你的主题模板是什么样子的更多细节，很难说更多。

【讨论】：

感谢戴夫的快速回复。我已经按照您提供的链接的建议浏览了所有文档，并且对建议的设置进行了短暂的尝试，但无济于事。听起来我可能不得不在迭代繁重的页面上使用 JSTL，因为它们是唯一似乎成为瓶颈的页面。我使用简单的主题并使用纯 HTML/CSS 构建我的所有 JSP 演示文稿，因此那里不应该有任何挂断。我将把我的迭代部分拆分为包含并用 JSTL 标记它们。
我愿意。一段时间以来，OGNL 的糟糕表现一直是我们的痛处。开始尝试使 EL 引擎可更换（我们的目标是 MVEL），但我认为这不会被纳入任何版本......不过，这可能是我们非常仔细地看待的事情。
刚刚在做一些研究时遇到了这个问题，觉得你可能会觉得它很有趣：struts.apache.org/2.2.3.1/docs/…
已经有一个请求包装器将检查值堆栈（我不记得首先检查哪个，堆栈或普通 EL 范围）。换句话说，您已经可以使用 JSP EL 来访问值堆栈上的对象。许多文档是从原始 WW 代码和非常早期的 S2 代码中遗留下来的。（顺便说一句，我是 Struts 提交者/Struts PMC 成员。）
很高兴知道。看来我明天有一些重新编码要做。感谢戴夫的提示。