Proposal to improve performance optimization of AbstractHandlerMethodMapping mapping matching

[conneyjoo]

Hello

First of all, thank you for your great work on Spring-WebMVC. The request mapping mechanism has served developers well over the years, and I really appreciate the thoughtfulness behind its design.

In a project with a large number of variable-style APIs, i am observed performance bottlenecks due to the linear search approach in RequestMappingHandlerMapping. To address this issue, I tried a hierarchical path matching mechanism that organizes the path in a structured way to narrow the search scope by splitting the path into multiple layers using the "/" symbol and utilizing the hierarchical structure to optimize the lookup process. This approach showed good results in optimizing lookup performance.

I am looking forward to whether this approach is in line with Spring's design principles, and if so, I will cooperate on how to improve it together to ensure that it fits well with the existing ecosystem. If this idea resonates, I will be happy to further refine the proposal based on feedback.

Thank you.

This is the detailed design document, which contains the code implementation, unit test, AbstractHandlerMethodMapping and optimized comparison JHM Report

[bclozel]

Hello @conneyjoo and thanks for the detailed proposal.
At one point I had an implementation for this but decided to not pursue because the performance degradation was too high when the application had fewer and simpler endpoints. I'm happy to revisit that decision. Did you compare against this case as well in your benchmarks?

[conneyjoo]

Hello @conneyjoo and thanks for the detailed proposal. At one point I had an implementation for this but decided to not pursue because the performance degradation was too high when the application had fewer and simpler endpoints. I'm happy to revisit that decision. Did you compare against this case as well in your benchmarks?

Thank you very much for your attention. In this document, I have listed benchmarks for two different specifications. I'm not sure if they match the "fewer and simpler endpoints" scenario you mentioned. If not, I can easily run another benchmark based on your specifications.

The link above section 4 of the document.
4. Performance Testing
Test Specifications:
A: 2 controllers, 64 mappings
B: 5 controllers, 156 mappings

[bclozel]

Can you share the implementation and JMH benchmark?

[conneyjoo]

Can you share the implementation and JMH benchmark?

Sure.
implementation:
https://github.com/conneyjoo/spring-framework/blob/main/spring-webmvc/src/main/java/org/springframework/web/servlet/mvc/method/LayeredRequestMappingHandlerMapping.java

jmh:
https://github.com/conneyjoo/spring-framework/blob/main/spring-webmvc/src/jmh/java/org/springframework/web/servlet/mvc/method/LayeredRequestMappingHandlerMappingBenchmark.java
https://github.com/conneyjoo/spring-framework/blob/main/spring-webmvc/src/jmh/java/org/springframework/web/servlet/mvc/method/RequestMappingHandlerMappingBenchmark.java

[bclozel]

Sorry for the late feedback.
I've had a look and the benchmarks you've been using are unfortunately not really meaningful. They're heavily biased towards deeply nested paths; in this case, a hierarchical approach is indeed likely to perform better. Also, each benchmark is repeating the exact same request; constant folding and other JVM optimizations will change the result.

I think using a smaller set of routes, with a lower nesting level is likely to show the results we had when we worked on this a few years ago:

1. hierarchical routing approaches work well when there are a lot of routes, all deeply nested. In this case, the complexity of the routing algorithm is offset by the fact that we are skipping many routes
2. requests against the root or URLs with a single path element will perform significantly worse. While many applications have multiple routing nesting levels, things like serving static resources is very common and likely to require matching in all cases.
3. PathPatternParser has made a important difference compared to AntPathMatcher and this offsets a lot of the performance difference

I don't think we're ready to invest more in this space at the moment. Feel free to contribute this variant as an independent library or Spring Boot starter, since this seems to be efficient for some types of applications. Thanks!