Hi Willy, On Mon, Oct 12, 2026, Willy Tarreau wrote: > I was having other use cases in mind that are relatively common, which > consist in setting access restrictions (auth or rate) per (ip, url). > [...] > Usually for such things, it works by longest match, exactly like IP > addresses, with a longest match (i.e. map_beg).
Fair point. To clarify how I see the selector: it is purely a grouping mechanism for performance. It only partitions the entries; inside a group, the underlying match method keeps its usual semantics and the file order is preserved, and groups never interleave. So what I care about is that picking the group is cheap and unambiguous, and that it has no effect on map order. >From that angle, both exact and longest-prefix (map_beg style) selection look fine to me: each resolves a request to a single group, and your "<class>_<customer>_" example fits naturally. Regex selection is the one I would rule out, since it would have to walk candidate selectors and could make several groups match, which defeats the purpose. So I'd propose exact match as the default, with longest-prefix selection as an option (or a follow-up that the structure already allows), and no regex. For what it's worth, in our own build the grouped lookup turned out to be much faster than the plain maps it replaced. Selecting the group by exact backend name first narrows the lookup to that backend's entries, and that is where most of the gain comes from. > Wow, this is huge! How is this possible ? Were your map files large ? > [...] > if you could at least run perf record on "haproxy -c -f config.cfg" > then share the output of "perf report" so that we figure where that > time is spent, it would be nice. Let me give a bit more detail on the layout, since "800 files" was probably an underestimate. Each backend had its own set of map files, one per purpose, and they used different match methods: map_reg for URL and header patterns, map_beg for paths, map_ip for address lists, plain string maps for exact keys, and so on. Every new backend added a whole new set of files of different types, plus the matching rules in the configuration. So the cost grew with the number of backends, and the more backends we had, the worse it got. What I can say for sure is that reload got clearly slower as the number of map files grew, and that it became much faster as soon as we consolidated them into a few files. Unfortunately I don't have the room to roll our setup back to the old layout just to profile it. Would you be able to try it on your side? A few hundred backends, each with its own reg/beg/ip/str maps and rules, compared with the same entries merged into one file per match type, should show it. If there is a linear lookup on map names somewhere, I'd be happy to help fix that too, independently of the grouped map. Thanks again for digging into it, Jinho
