我们使用的Grails 2.2.4、WebSphere 8.0.0.5都运行在AIX 6.1.0.0上。Websphere正在使用IBM JDK:
Java（TM）SE运行时环境（构建pap6460_26sr3ifix-20121005_02（SR3+IV27268+IV27928+IV28217+IV25699））
IBM J9 VM（内部版本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"
是缓慢的，我的意思是用20秒的时间来呈现一个小的GSP。有趣的是，在我们的本地开发环境中，这需要2秒钟。
我们通过让一个控制器在模型中没有任何内容的空白GSP上只调用render（..）来隔离这个问题，所以我只能假设这是编译，但我可能错了。
有没有人遇到过其他呈现GSP非常慢的例子，或者有任何建议，也许是AIX上的某种奇怪的JDK问题？
除了奖金，答对的人还可以得到免费的华夫饼。
EDIT前几天刚刚注意到：有三个环境具有相同的WAS配置和设置，其中一个运行良好，因此这肯定是某种环境问题。
我同意您的怀疑，即现在是编译时间。也许grails.gsp.view.dir速度较慢——也许是网络文件系统？
不幸的是，真正的答案是不允许在生产中重新装载GSP。这显然是为了方便开发，而不是为了在生产中表现良好。
确保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
还要记住，视图路径必须以斜线结尾。我在你提供的例子中没有看到这一点。
虽然我不能告诉您问题的原因，但我可以为您指出一个可以帮助您调查性能问题的工具。
Grails Miniprofiler插件是一个非常棒的工具，可以检查端到端的性能，一直到视图（您认为问题所在）。
在我的一个项目中的一些GSP上，我惊讶地发现一些视图相对于SQL调用（通过延迟加载）变得如此沉重。
你可能会怀疑问题出在哪里，也许你在特定平台上遇到了一个不知名的错误，但有确凿的数字来指出瓶颈是非常有用的。
值得一提的是，我还没有在我的任何操作系统/环境中看到您描述的问题。但我确实记得在尝试部署到JBoss 6.1时遇到了严重的痛苦（自从解决后），所以我对Grails在某些环境中可能存在问题的想法很敏感。
祝你好运。。。
Grails Miniprofiler插件
我们的应用程序也遇到了同样的问题，该应用程序试图在Gsp页面上呈现Birt报告（在prod服务器上需要5分钟的时间，我们使用了Tomcat和Mysql），但没有回答，而是建议您可能需要使用grails缓存插件，该插件可以根据您的需求缓存Gsp页面。
grails.org/plugin/cache
原来问题是https://plugins.grails.org/plugin/sergiomichels/grails-melody-plugin.谁知道呢！