7

We are using Grails 2.2.4, WebSphere 8.0.0.5 all running on AIX 6.1.0.0. Websphere is using the IBM JDK:

Java(TM) SE Runtime Environment (build 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 enabled, AOT enabled)

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

The problem is that using:

grails.gsp.enable.reload = true
grails.gsp.view.dir="/path/to/gsp/views"

is slow, and by that I mean a good 20 seconds to render a small GSP. What's interesting is that in our local development environments it takes 2 seconds.

We've isolated this problem by having a controller that does nothing except call render(..) on a blank GSP with nothing in the model, so I can only assume it's the compilation but I could be wrong.

Has anyone come across other instances where rendering GSPs is extremely slow, or have any suggestions, perhaps it's some sort of weird JDK issue on AIX?

In addition to the bounty, whoever answers this correctly gets free waffles.

EDIT Just noticed this the other day: there are three environments with the same WAS config and setup and one of them works fine, so it is definitely some sort of environment issue.

Community
  • 1
  • 1
Alex Beardsley
  • 20,988
  • 15
  • 52
  • 67
  • Could you try and do a dd test on /path/to/gsp/views? – JavaDev Aug 13 '13 at 23:26
  • When you say local development environment, is it local WAS environment or embedded Tomcat in grails? – dmahapatro Aug 14 '13 at 15:13
  • I suspect you've already looked at the memory angle, but I have run into similar oddball cases when under memory pressure. A lengthy, possibly relevant discussion here: http://grails.1312388.n4.nabble.com/Grails-performance-restriction-td4642061.html Particularly, Graeme's reply on Mar 05, 2013; 5:48am – Andrew Aug 15 '13 at 09:49
  • I did try dd actually. – Alex Beardsley Aug 16 '13 at 15:02
  • @dmahapatro It was embedded Tomcat in grails. – Alex Beardsley Aug 16 '13 at 15:02
  • Can that be tried in local WAS environment? I am skeptical about the IBM JDK version ([SDK 1.6.1 for WAS 8.0.0.5](http://www-01.ibm.com/support/docview.wss?uid=swg27005002)). If issue is replicated in dev, I would try upgrading WAS with SDK 1.7? – dmahapatro Aug 16 '13 at 15:11

5 Answers5

1

I agree with your suspicion that it's compilation time. Perhaps you grails.gsp.view.dir is slow - a networked file system perhaps?

The real answer, unfortunately, is to not enable GSP reload in production. It's clearly meant as a development convenience, and is not intended to perform well in production.

GreyBeardedGeek
  • 29,460
  • 2
  • 47
  • 67
  • Unfortunately we have no choice since the requirement is to allow people to change it on the fly. – Alex Beardsley Aug 13 '13 at 23:22
  • 1
    Sounds like you need a CMS – GreyBeardedGeek Aug 14 '13 at 03:43
  • Can you try running with the same enabled reload but just use tomcat? I am guessing it is WAS related problem – JavaDev Aug 15 '13 at 06:21
  • We are using a CMS actually. The way it works (this isn't our design) is that when someone publishes changes in the CMS, it replaces the GSP, hence the need for reloading. The GSP has taglibs on it that they can use. – Alex Beardsley Aug 16 '13 at 14:59
  • @JavaDev there are 3 separate AIX environments and one of them is actually fast and has the same WAS setup & configuration, so it is definitely something with the environment. – Alex Beardsley Aug 16 '13 at 15:07
1

Make sure sitemesh is being preprocessed

grails.views.gsp.sitemesh.preprocess=true

Also I suspect this to be locking issue rather than compiling issue.

To at least reduce this problem set the following configs

grails.gsp.reload.interval= time in milliseconds.

something high depending on your comfort. Perhaps every hour?

If your file is changing the last modified time too quickly you need to lower the granularity by

grails.gsp.reload.granularity= Time in milliseconds.

Limit the number of classes being reloaded by

grails.reload.excludes

and 

grails.reload.includes

Also remember the view path MUST end in slash. I didn't see that in the example you provided.

Ganesh Krishnan
  • 7,155
  • 2
  • 44
  • 52
1

While I can't tell you what is the cause for your problem, I can point you to a tool that could help you look into the performance problem.

The Grails Miniprofiler plugin is a fantastic tool for examining end to end performance, all the way to the view (which is where you believe your problem is).

On some GSPs on a project of mine, I was surprised to see how heavy some views got with respect to the SQL calls (via lazy loading).

You may have suspicions for where the problems lie, and maybe you're hitting an obscure bug on that specific platform, but having hard numbers to point to bottlenecks is extremely useful.

For what it's worth, I haven't seen the problem you've described in any of my OS/environments. But I do remember experiencing serious pain with trying to deploy to JBoss 6.1 (since resolved) so I am sensitive to the idea that Grails could have issues on some environments.

Best of luck...

Grails Miniprofiler plugin

Michael Morett
  • 56
  • 5
0

We are having the same problem on our application that tried to render a Birt report on Gsp page(it takes some times 5 minutes on prod server,We used Tomcat and Mysql) , not answer but a suggestion you might need to use the grails cache plugin ,that has a capability of cache gsp pages based on you requirement.

grails.org/plugin/cache‎

Develop4Life
  • 7,581
  • 8
  • 58
  • 76
0

Turned out the problem was https://plugins.grails.org/plugin/sergiomichels/grails-melody-plugin. Who knew!

Lifeweaver
  • 986
  • 8
  • 29
Alex Beardsley
  • 20,988
  • 15
  • 52
  • 67