我们正在使用在AIX 6.1.0.0上运行的Grails 2.2.4，WebSphere 8.0.0.5。 Websphere正在使用IBM JDK：
Java（TM）SE运行时环境（构建pap6460_26sr3ifix-20121005_02（SR3 + IV27268 + IV27928 + IV28217 + IV25699））
IBM J9 VM（build 2.6，JRE 1.6.0 AIX ppc64-64 20120919_122629（已启用JIT，已启用AOT）
J9VM - R26_Java626_SR3_iFix_1_20120919_1316_B122629
JIT - r11.b01_20120808_24925ifx1
GC - R26_Java626_SR3_iFix_1_20120919_1316_B122629 J9CL - 20120919_122629）
JCL - 20120713_01
问题是使用：
grails.gsp.enable.reload = true
grails.gsp.view.dir="/path/to/gsp/views"
速度很慢，我认为渲染一个小型GSP需要20秒。有趣的是，在我们的本地开发环境中需要2秒钟。
我们已经通过控制器除了在模型中没有任何内容的空白GSP上调用渲染（...）之外什么也没做什么来解决这个问题，所以我只能假设它是编译但我可能是错的。
有没有人遇到过渲染GSP速度极慢的其他实例，或者有任何建议，或许这是AIX上某种奇怪的JDK问题？
除了赏金之外，无论谁正确回答这个问题都可以免费获得华夫饼。
编辑前几天注意到这一点：有三个环境具有相同的WAS配置和设置，其中一个工作正常，所以它肯定是某种环境问题。
答案 0 :(得分：1)
我同意你的怀疑，这是编译时间。也许你grails.gsp.view.dir很慢 - 也许是网络文件系统？
遗憾的是，真正的答案是不在生产中启用GSP重新加载。 它显然意味着开发方便，并不打算在生产中表现良好。
答案 1 :(得分：1)
确保正在预处理sitemesh
grails.views.gsp.sitemesh.preprocess=true
此外，我怀疑这是锁定问题而不是编译问题。
要至少减少此问题，请设置以下配置
grails.gsp.reload.interval= time in milliseconds.
如果您的文件过早更改上次修改时间，则需要按
降低粒度grails.gsp.reload.granularity= Time in milliseconds.
通过
限制重新加载的类数grails.reload.excludes
和
grails.reload.includes
还要记住视图路径必须以斜线结尾。我在你提供的例子中没有看到。
答案 2 :(得分：1)
虽然我无法告诉您问题的原因，但我可以为您指出一个可以帮助您查看性能问题的工具。
Grails Miniprofiler插件是用于检查端到端性能的绝佳工具，一直到视图（这是您认为问题所在的位置）。
在我的一个项目的一些GSP上，我惊讶地发现一些观点在SQL调用方面有多么沉重（通过延迟加载）。
你可能怀疑问题在哪里，也许你在这个特定的平台上遇到了一个模糊的错误，但是有难以指出瓶颈的数据非常有用。
对于它的价值，我没有看到你在我的任何操作系统/环境中描述的问题。但我确实记得尝试部署到JBoss 6.1时经历了严重的痛苦（自解决以来），因此我对Grails在某些环境中可能存在问题的想法很敏感。
祝您好运......
答案 3 :(得分：0)
我们在尝试在Gsp页面上呈现Birt报告的应用程序上遇到了同样的问题（在prod服务器上花了5分钟，我们使用了Tomcat和Mysql），没有回答，但建议您可能需要使用grails缓存插件，具有基于您的要求缓存gsp页面的功能。
答案 4 :(得分：0)
原来问题是http://grails.org/plugin/grails-melody。谁知道！