Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance Optimization In GrailsControllerUrlMappingInfo #9886

Closed
ctoestreich opened this issue Apr 20, 2016 · 15 comments
Closed

Performance Optimization In GrailsControllerUrlMappingInfo #9886

ctoestreich opened this issue Apr 20, 2016 · 15 comments

Comments

@ctoestreich
Copy link
Contributor

@ctoestreich ctoestreich commented Apr 20, 2016

We are seeing consistently bad/long running performance against GrailsControllerUrlMappingInfo in instrumented code in our running application. However the tools we are using don't offer any deeper insight into the actual issue. Our UrlMappings files have 70 mappings in them. This could be related to the @Delegate. Any thoughts on this before I go chasing down ways to make this faster? This accounts for a large chunk of most of our request overhead in the application. There is a potential huge core grails bottleneck that can be freed up by optimizing this code. I wanted to log this here so I have something to post comments to that is not lost in slack.

screen shot 2016-04-20 at 4 07 24 pm

screen shot 2016-04-20 at 3 33 46 pm

@ColinHarrington

This comment has been minimized.

Copy link
Contributor

@ColinHarrington ColinHarrington commented Apr 20, 2016

What version of Grails? Java? OS?

@ctoestreich

This comment has been minimized.

Copy link
Contributor Author

@ctoestreich ctoestreich commented Apr 21, 2016

Grails 3.1.0 - 3.1.5
Java 8u72
OS Red Hat Enterprise Linux Server release 7.2 (Maipo)

@ctoestreich

This comment has been minimized.

Copy link
Contributor Author

@ctoestreich ctoestreich commented Apr 21, 2016

@ColinHarrington Have any spare yourkit licenses laying around!? 😆

@ctoestreich

This comment has been minimized.

Copy link
Contributor Author

@ctoestreich ctoestreich commented May 3, 2016

Closing until we can isolate and pinpoint.

@ctoestreich ctoestreich closed this May 3, 2016
@ghost

This comment has been minimized.

Copy link

@ghost ghost commented May 12, 2016

I am seeing the same problem as well. We are using New Relic to track performance and apparently our biggest bottle neck is GrailsControllerUrlMappingInfo.

We have around 50 entries in our UrlMapping. An example of such an entry will be:

group("/api") {
            "/deployments"(controller: "deployments", action: "list", method: "get")
}
@graemerocher

This comment has been minimized.

Copy link
Member

@graemerocher graemerocher commented May 12, 2016

An example on github that reproduces the issue would be good

@graemerocher

This comment has been minimized.

Copy link
Member

@graemerocher graemerocher commented May 12, 2016

@ctoestreich

This comment has been minimized.

Copy link
Contributor Author

@ctoestreich ctoestreich commented May 12, 2016

@sergiodelamoshoptimix We assume this an issue with how New Relic instruments the code. I think the GrailsControllerUrlMappingInfo.groovy class is involded in every request to resolve the actual class that does the work and the New Relic Instrumentation stops at this class or thinks this is the actual class that is running when it appears that the class actually is delegating the work which NR must not like. We are still looking at other tools to see if we can hammer out actual perf problems.

@sdelamo

This comment has been minimized.

Copy link
Contributor

@sdelamo sdelamo commented May 13, 2016

@graemerocher @ctoestreich Thanks for the explanation. I think you are right and New Relic is attributing most of the executing time to GrailsControllerUrlMappingInfo while the time is actually spent in Controllers and Services.

@benorama

This comment has been minimized.

Copy link

@benorama benorama commented May 15, 2016

@sdelamo did you report the issue to NewRelic?

It looks like they officially support 1.x and 2.x version, but maybe not yet 3.x?
https://newrelic.com/java/grails

@ColinHarrington

This comment has been minimized.

Copy link
Contributor

@ColinHarrington ColinHarrington commented May 16, 2016

@sdelamo This behavior is similar to what we saw before New Relic supported Grails 1.x or 2.x. I would guess that they have a little bit of work to do to support Grails 3

@ColinHarrington

This comment has been minimized.

Copy link
Contributor

@ColinHarrington ColinHarrington commented May 16, 2016

I've requested that they do the same for Grails 3
Feature Request

@ctoestreich

This comment has been minimized.

Copy link
Contributor Author

@ctoestreich ctoestreich commented May 16, 2016

One thing that helps is to turn off Auto Naming for transactions in your New Relic account.

@ctoestreich

This comment has been minimized.

Copy link
Contributor Author

@ctoestreich ctoestreich commented May 16, 2016

Reference

Disabling component-based naming

For some applications, you may want to disable component-based transaction naming. Set this value in your newrelic.yml file:
enable_auto_transaction_naming: false
Unless you implement API calls to name your transactions, disabling auto-transaction naming is very likely to cause Metric grouping issues.

Per their docs you may have to add back in the group mapping url stuff. We got burned on our /search endpoint and had to add a /search/* mapping to group with the auto naming off.

@sdelamo

This comment has been minimized.

Copy link
Contributor

@sdelamo sdelamo commented Jun 6, 2016

Hi @ctoestreich Thanks for suggesting the disabling component-based naming. It helps indeed.

@benorama , I have upvoted the @ColinHarrington feature request. Lets see if they bring Grails 3 support on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.