Slowness after migrating to Grails 5.1.1 - time spent on GrailsControllerUrlMappingInfo-CodePudding

The

NewRelic is showing that org.grails.web.mapping.mvc.GrailsControllerUrlMappingInfo is to blame. There is nothing else underneath it that is slow. Digging a bit deeper, we found an

From that little execution time logger I've got 161ms

Given all of that, it looks like NewRelic is kinda right. Something else is wasting cycles. The biggest question is WHAT?

How can I profile that? Maybe someone came across a similar situation. How can I resolve it?

On another note, since we have all the possible monitoring tools in place, I can tell for sure that the servers are not doing much (including the DB). The allocated heap size is up to 3G. Usually, the first request to the same endpoint takes much longer, and the consecutive ones are much better but still slow.

UPDATE

Decided to dig deeper. Hooked up the Async Profiler and I think my original assumptions were proved true.

The class loader seems to be the one causing the performance issues. This also explains the slowness of the first request (of any type), while subsequent ones start working faster. But, if I do the same call in another 4-5 minutes, it loads the classes again and is slow.

So, unless I am mistaken, the issue here is the class loader. I am blaming TomcatEmbeddedWebappClassLoader for this.

Now, the biggest question is how do I fix that in Grails? I am running a war file in prod -> java -Dgrails.env=prod -Xms1500m -Xmx3000m -jar app.war

I found this post that is somewhat in the same direction, but I am not sure how to wire it in, in Grails.

UPDATE #2

Looking for the class loader solution brought me to this issue. The proposed solution is for Spring. I am wondering what is the way to solve that for grails.

CodePudding user response：

In the link https://github.com/spring-projects/spring-boot/issues/16471 has the following report:

"It's quite low priority as the problem can be avoided by using .jar packaging rather than .war packaging or, I believe, by switching to another embedded container. As things stand, we have no plans to tackle this in the 2.x timeframe."

So I ran the command './gradlew bootJar'.

And I did the test with siege and the first request was from 1.62 seconds to 0.47 seconds

CodePudding user response：

Run the siege command to check the total time of several users making the request at the same point.

I made a repository trying to do what you said

https://github.com/fernando88to/slowness5