Description
Hey team !
We have an interesting issue where our propertySource use can be CPU taxing on our systems due to 1/ many propertySources setup (sometimes 80+), 2/ many properties setup over those propertySources (sometimes 1000+).
It seems like the reason is the support for relaxed binding and use of ConfigurationPropertySourcesPropertySource in the first position of the list of propertySources although it can be reproduced when "forced" in last position as well. The property resolution is doing a breadth first search of all possible bindings in this layer then it's doing an exact match again a second time. Our flamegraph have revealed a lot of String manipulations happening in hot paths where we use environment.getProperty.
In our use cases we use environment.getProperty sometimes more than once per request since some properties could have changed. One use case for instance is a dynamic timeout. I imagine any use case with a MutablePropertySource used in a request or messaging path would reproduce that problem.
We are envisioning caching as a possible solution:
- a new first position property source acting as a cache
- caching hit and misses and if a mutable source is present, syncing any refresh with this cache
- optionally providing metrics to that cache to analyse property resolutions patterns
The cache could be lazily built or partially (maybe fully?) hydrated on startup if desired although this should be an opt-in given the impact it could have on startup time.