tom*_*tom 12 performance groovy playframework
从他们的网站http://www.playframework.org/documentation/1.0/faq
"目前Play堆栈中最大的CPU消费者是基于Groovy的模板引擎.但是由于Play应用程序很容易扩展,如果你需要提供非常高的流量,它就不是一个真正的问题:你可以平衡我们希望通过新的JDK7以及对动态语言的更好支持,在这个级别上获得性能提升."
那么没有更好的选择吗？JSP怎么样？
And*_*eis 12
JSP不可行,因为每个JSP都编译为Servlet,而servlet API提供的服务器端会话与RESTful范例不兼容.我们不想回到可扩展性很差的服务器端会话的黑暗时代,回到浏览器中的按钮问题,重新发布等等.
Japid模板很有趣,但它们并没有得到一个伟大的社区的支持,甚至在创建游戏时甚至不存在(我不确定).我在我自己的应用程序中尝试使用Japid作为Groovy模板的替代品,并在JMeter测试中发现,这种好处只是微不足道的,10%到最大值.提高25%.
我想最终这一切都取决于您的可扩展性要求和页面结构.我选择了应用程序的90%用例并进行了测试.对我来说,这种小改进并不能证明额外依赖的额外成本(我喜欢将依赖关系保持在可维护性的最小值).
Groovy模板通常不坏或慢.尽可能使用类型变量(而不是"def"),即使在闭包中也是如此!将访问属性的值保存在局部变量中.分页做得合理.然后保持手指交叉,以后GSP可以在groovy ++上运行,你就完成了;)
对我来说,问题不是为什么他们在观点中使用了groovy.也就是说,因为我宁愿在控制器层中错过它.Groovy会使控制器行为编码变得更容易恕我直言.
首先,JSP不是Play的有效选项,因为它选择不沿着Java EE路由(JSP是其中的一部分).相反,Play选择使用Groovy作为一个直观,简单但功能强大的模板引擎.
然而,Play最大的特点之一是它是一个可插拔的系统,这意味着可以简单地替换核心系统的许多部分.这包括模板引擎,还有一些已经可用.
最受欢迎的是Japid.它声称比标准模板引擎快2-20倍,并且已经存在了一段时间.有关详细信息,请参阅此处http://www.playframework.org/modules/japid.
第二种选择是剑桥,虽然这只是一段时间,但在留言板中相当活跃(参见https://groups.google.com/forum/?hl=en#!searchin/play-framework/cambridge/play-framework/IxSei-9BGq8/X-3pF5tWAKAJ).
我倾向于坚持Groovy,因为我喜欢它的工作方式,并且没有发现它在性能方面太糟糕,但每个应用程序都是个性化的,所以你自己的性能测试应该引导你走自己的特定道路.