Grails 2.0 的性能真的那么低吗？
Posted
技术标签:
【中文标题】Grails 2.0 的性能真的那么低吗？【英文标题】：Is performance of Grails 2.0 really that awfully low? 【发布时间】：2012-02-09 01:02:21 【问题描述】：我对基于 JVM 堆栈的 WEB 开发有点新手，但未来的项目将特别需要一些基于 JVM 的 WEB 引擎。所以我开始寻找一些基础来快速制作东西，然后转而尝试 Grails。书上的东西看起来不错，但是由于很长的启动时间（grails run-app）给我留下了深刻的印象，我决定测试它在负载下是如何工作的。这里是：
测试应用程序：按照这里的一些说明从地面制作它（假设您已经安装了 Grails 和 Tomcat，需要 2 分钟）：
_http://grails.org/Quick+Start
测试用例（带有 Apache 基准 - 带有 Apache httpd - _http://httpd.apache.org）：
ab.exe -n 500 -c _http://localhost:8080/my-project/book/create （注意：这只是在样式化容器中显示 2 个输入字段）
硬件：Intel i5 650 (4Core*3.2GHz) 8GB Ram & Win Server 2003 x64
结果是..
Grails：32 个请求/秒
Total transferred: 1380500 bytes
html transferred: 1297500 bytes
Requests per second: 32.45 [#/sec] (mean)
Time per request: 308.129 [ms] (mean)
Time per request: 30.813 [ms] (mean, across all concurrent requests)
Transfer rate: 87.51 [Kbytes/sec] received
（只有 32 Req/Sec 和 100% 的 CPU 饱和度，这太低于我对此类硬件的预期）
...接下来-我尝试将它与类似的虚拟 JSF 应用程序进行比较（我在这里拿了一个：_http://www.ibm.com/developerworks/library/j-jsf2/ - 查找“源代码有 JAR 文件”，里面有 \jsf-example2\target\jsf-example2-1.0.war），
测试用例：ab.exe -n 500 -c 10 _http://localhost:8080/jsf/backend/listing.jsp结果是..
JSF：400 请求/秒
Total transferred: 5178234 bytes
HTML transferred: 5065734 bytes
Requests per second: 405.06 [#/sec] (mean)
Time per request: 24.688 [ms] (mean)
Time per request: 2.469 [ms] (mean, across all concurrent requests)
Transfer rate: 4096.65 [Kbytes/sec] received
...最后是原始的虚拟 JSP（仅供参考）
Jsp：8000 请求/秒：
<html>
<body>
<% for( int i = 0; i < 100; i ++ ) %>
Dummy Jsp <%= i %> </br>
<% %>
</body>
</html>
结果：
Total transferred: 12365000 bytes
HTML transferred: 11120000 bytes
Requests per second: 7999.90 [#/sec] (mean)
Time per request: 1.250 [ms] (mean)
Time per request: 0.125 [ms] (mean, across all concurrent requests)
Transfer rate: 19320.07 [Kbytes/sec] received
...
我错过了什么吗？ ... Grails 应用程序可以运行得更好？
PS：我尝试使用 VisualVM 分析我正在运行的 Grails 应用程序，但收到了无限循环的消息，例如...
Profiler Agent: Redefining 100 classes at idx 0, out of total 413
...
Profiler Agent: Redefining 100 classes at idx 0, out of total 769
...
最后，应用程序在几分钟后停止工作 - 所以，看起来分析 Grails 不是良好诊断的选择。
更新 - - - - - - - - - - - - - - - - - - - - - - - - - - - -
首先我必须管理，是的，我需要 RTFM - 即“grails run-app”不是运行 Grails 进行性能测量的正确方法。在编译 WAR 并将其部署到 Tomcat 之后，性能并没有那么低——它只是很低。下面的指标是针对 1 个用户的并发性（我只是想检查一个线程中框架的 MAX 性能并且没有重负载），在阅读其他相关帖子时，我来到“http://***.com/ questions/819684/jsf-and-spring-performance-vs-poor-jsp-performance" 并决定检查那里提到的 Apache Wicket - 它的性能也包括在内。
用例是： - ab.exe -n 500 -c 1 _http://localhost:8080/... - 服务器是 vFabric tcServer 开发版中的 Tomcat7，在后台运行“洞察”
---------------------- tcServer Plain Tomcat 7 -c 10
/Grails/book/create 77 req/sec 130 req/sec 410 req/sec
/jsf/backend/listing.jsp 133 req/sec 194 req/sec 395 req/sec
/wicket/library/ 870 req/sec 1400 req/sec 5300 req/sec
所以……无论如何，Grails 有问题。我已经使用 tcServer 进行了一些分析（感谢 Karthick） - 看起来它只能跟踪“基于 Spring”的操作，Grails 的内部堆栈跟踪如下（对于 2 个请求 - 注意：指标不稳定 - 我打赌准确性tcServer 远非完美，但只能用于信息）
Total (81ms)
Filter: urlMapping (32ms)
-> SimpleGrailsController#handleRequest (26ms)
-> Render view "/book/create" (4ms)
Render view "/layouts/main.gsp" (47ms)
Total (79ms)
Filter: urlMapping (56ms) ->
-> SimpleGrailsController#handleRequest (4ms)
-> Render view "/book/create" (38ms)
Render view "/layouts/main.gsp" (22ms)
PS：Grails 性能不佳的根本原因可能是底层的“Spring”库，将更详细地检查这一点。
【问题讨论】：
我会编辑你的第一篇文章，因为你知道你的 Grails 基准很糟糕。 【参考方案1】：你是否使用 run-app 运行它？
http://grails.org/Deployment 状态：
“永远不要使用 grails run-app 命令部署 Grails，因为这会将 Grails 设置为“开发”模式，这会产生额外的开销。”
【讨论】：
是的 - 我 是 使用“grails run-app”运行它，请参阅我的评论以获得另一个回复。但是，我希望即使在 Prod 中也可以动态更新我的应用程序，并且看起来在 Tomcat 下更改 *.gsp 文件没有任何效果。所以......选择是使用“grails run-app”运行还是拥有一个静态站点:( 我认为，如果您想在生产中动态更新代码而不重新部署，那么您应该找到另一个框架/平台。 Grails（以及大多数基于 JVM 的框架）并不是真正为此而设计的。 @XtraCoder RTFM 6.2.7 Making Changes to a Deployed Application @JamesA 很好的发现，但不知道 F 是必要的。 @typoknig 我当然不打算将其视为负面意义，只是对常用缩写的快速评论。下次我会更加小心/敏感。感谢您提请我注意。【参考方案2】：尝试将您的示例应用部署到 tomcat。 grails run-app 仅用于开发。
【讨论】：
_是的，Tomcat 下的 Grails 给出的结果有点接近 JSF 应用程序 - 390req/sec（尽管吞吐量降低了 4 倍）。仍然......它足够好:)吗？ - 与 JSP 相比，我希望大约 1000 个 req/seq 更适合这样一个简单的页面_ 并且仍然没有性能分析，控制台中的另一条消息，但结果相同 *** Profiler 引擎警告：目标 VM 无法加载类以检测 java_lang_Long$getLong *** 可能它最近已被卸载 您可以尝试使用 spring tcServer 进行分析。这也可作为 STS 捆绑包使用 在用户邮件列表中查看此线程：grails.1312388.n4.nabble.com/… - 特别是，如果您需要每秒额外的请求，禁用 Hibernate OpenSessionInViewInterceptor 会有很大的不同。【参考方案3】：您是在哪个环境中启动应用程序的？产品？开发者？
你使用脚手架吗？
我已经在我的机器上试过了（核心 i7-2600k）。一个带有 4 个输入字段、动态布局和其他一些东西的登录页面。在较慢的开发环境中，我每秒收到 525 个请求。
【讨论】：
我不知道你所说的 dev 或 prod 是什么意思。这是我的开发工作站。脚手架？ - 是的，据我了解。 您可以在不同的“环境”中启动 grails。只需运行“grails prod run-app”进行生产（更快）或“grails run-app”进行开发。脚手架很慢，不要在生产环境中使用它。简单的说：如果你使用它，每个请求都会在后台生成大量代码。【参考方案4】：是的，这是一个对 grails 或他的环境不太了解的人的基准；首先，他在 Windows 上运行以不擅长资源管理而闻名，这就是为什么大多数 Web 服务/应用程序服务都在 Linux 环境中运行。
其次，如果他使用“ab”进行基准测试，那么他没有设置代理缓存，因为在第一次命中后，其余的命中将被缓存，而据我所知，他现在正在对他的缓存进行基准测试他的设置。
所以这一切看起来就像是对一个糟糕的设置和对 Grails 的理解不足的基准测试。无意冒犯。
【讨论】：
以上是关于Grails 2.0 的性能真的那么低吗？的主要内容，如果未能解决你的问题，请参考以下文章