Spring Proposal to improve performance optimization of AbstractHandlerMethodMapping mapping matching

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

Comment From: 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?

Comment From: 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

Comment From: bclozel

Can you share the implementation and JMH benchmark?

Comment From: 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

Comment From: 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!

Comment From: conneyjoo

Hello Brian Clozel,

Thank you for taking the time out of your busy schedule to read these contents and point out so many detailed issues. I feel very happy. Your professional analysis has given me a clearer understanding of the direction for improving testing methods. Indeed, the current benchmark testing may have some bias, as there are many controllers that I copied from correctness function testing, mainly to make up for the number of controllers. Therefore, there are a bunch of chaotic deeply nested paths inside. In the future, I will try to optimize the test set to more comprehensively evaluate performance in different scenarios.

Your research achievements a few years ago laid an important foundation, and I greatly admire them. The improvement of AntPathMatcher and PathPatternParser has also brought significant performance improvements, and i understand the current priority considerations in this area. I have been using Spring MVC all along and have never had any problems. The features inside are very powerful. Almost all Java server developers are using it. So I repeated adding so many deeply nested paths before to ensure that it doesn't have any bugs in matching. The company I currently work for is using this optimization because my colleagues are all using the RESTful API. It has been integrated as an independent library in our project and works by simply enabling an annotation.

I am very willing to dedicate this achievement to Spring Boot Starter and feel extremely proud to contribute to Spring!

Regarding the root path or URL requests that only contain a single path element, I would like to add:

-For standard URLs, I have followed the same approach as AbstractHandlerMethodMapping, prioritizing HashMap-based matching.

-If the above processing is skipped, layered routing will exit this deep traversal in advance if it encounters a root path or only contains a single path element URL and matches a hit.Perhaps this is not exactly the scenario you were referring to.

Thank you again for your patient guidance and suggestions, and thank you to the Spring team for their outstanding contributions to the open source community over the years!.

Salute, ConneyJoo

发件人: Brian Clozel @.> 发送时间: 2025年3月10日 9:15 收件人: spring-projects/spring-framework @.> 抄送: conney @.>; Mention @.> 主题: Re: [spring-projects/spring-framework] Proposal to improve performance optimization of AbstractHandlerMethodMapping mapping matching (Issue #34461)

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:

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
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.
PathPatternParser has made a important difference compared to AntPathMatcher and this offsets a lot of the performance difference

― Reply to this email directly, view it on GitHubhttps://github.com/spring-projects/spring-framework/issues/34461#issuecomment-2709899462, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABO7DJYJUZYQX6PJUJ4MWL32TVJ3HAVCNFSM6AAAAABXQRZDLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBZHA4TSNBWGI. You are receiving this because you were mentioned.Message ID: @.***>

[bclozel]bclozel left a comment (spring-projects/spring-framework#34461)https://github.com/spring-projects/spring-framework/issues/34461#issuecomment-2709899462

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:

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
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.
PathPatternParser has made a important difference compared to AntPathMatcher and this offsets a lot of the performance difference

Comment From: bclozel

Thanks for the kind words and this amazing work.

We'll probably revisit this theme in the future, as the next major version will remove already a few deprecated matching options and let us revisit part of our implementation. Feel free to stay in touch and chat about your experiments, this is really useful.

Thanks!

Comment From: conneyjoo

Thanks! Really looking forward to it!

发件人: Brian Clozel @.> 发送时间: 2025年3月10日 15:09 收件人: spring-projects/spring-framework @.> 抄送: conney @.>; Mention @.> 主题: Re: [spring-projects/spring-framework] Proposal to improve performance optimization of AbstractHandlerMethodMapping mapping matching (Issue #34461)

Thanks for the kind words and this amazing work.

Thanks!

― Reply to this email directly, view it on GitHubhttps://github.com/spring-projects/spring-framework/issues/34461#issuecomment-2710925013, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABO7DJ6YR3TIREXU5WGY4UL2TWTMBAVCNFSM6AAAAABXQRZDLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMJQHEZDKMBRGM. You are receiving this because you were mentioned.Message ID: @.***>

[bclozel]bclozel left a comment (spring-projects/spring-framework#34461)https://github.com/spring-projects/spring-framework/issues/34461#issuecomment-2710925013

Thanks for the kind words and this amazing work.

Thanks!