performance - 为什么要玩!框架选择 Groovy 作为模板引擎

Question

从他们的网站 http://www.playframework.org/documentation/1.0/faq

”
此时 Play 堆栈中最大的 CPU 消耗者是基于 Groovy 的模板引擎。但由于 Play 应用程序易于扩展，因此如果您需要为非常高的流量提供服务，这并不是真正的问题:您可以平衡多个服务器之间的负载。我们希望通过新的 JDK7 及其对动态语言的更好支持在这个级别上获得性能提升。
”

那么就没有更好的选择了吗？ JSP呢？

Answer 1

JSP 是不可行的，因为每个 JSP 都编译为一个 Servlet，而 servlet API 提供了诸如与 RESTful 范式不兼容的服务器端 session 之类的东西。我们不想回到可扩展性极差的服务器端 session 、浏览器中的后退按钮问题、重新发布等的黑暗时代。

Japid 模板很有趣，但它们没有得到强大社区的支持，甚至可能在创建 play 时还不存在(不过我不确定)。我在自己的应用程序中尝试用 Japid 作为 Groovy 模板的替代品，并在 JMeter 测试中发现 yield 只是微不足道的，最多 10%。 25% 的改进。

我想最终这一切都取决于您的可扩展性要求和页面结构。我选择了我的应用程序的 90% 用例并进行了测试。对我来说，小小的改进并不能证明额外依赖的额外成本是合理的(为了可维护性，我喜欢将依赖保持在最低限度)。

Groovy 模板一般都不错或很慢。尽可能使用类型化变量(而不是“def”)，即使是在闭包中!将访问的属性值保存在局部变量中。做合理的结果分页。然后祈祷 GSP 将来可以在 groovy++ 上运行，你就大功告成了；)

对我来说，问题不在于他们为什么在 View 中使用 groovy。也就是说，因为我宁愿在 Controller 层中非常想念它。恕我直言，Groovy 将使编码 Controller 行为变得容易得多。