The ideas from #27 are interesting enough (especially from an optimization standpoint if you don't want to integrate a reverse proxy for caching purposes).
The https://www.drupal.org/project/page_cache_query_ignore → module seems to address a subset of the functionality without the necessary granularity for controlling the query strings supported for specific routes. The ideas proposed here can be potentially incorporated in that module.
- 🇫🇷France fgm Paris, France
@catch Do you have the reference of any issue of which this might be a duplicate ?
I agree that the mechanisms you mention may be part of the solution to the problem, but they are not sufficient on their own and do not reduce load as much as this would unless adding a lot more off-Drupal configuration.
If this issue was marked as a duplicate only because of these mechanisms, it does not seems like it is actually a duplicate, and would merit being pursued on its own.
- 🇫🇷France dakwamine
If this issue is resolved only by requiring external systems, I agree with @fgm to not mark this as duplicate.
The module shared by @codebymikey in the comment #29 implements some of the ideas from here, and can be augmented with other ones.
Listing some of the ideas gathered here so far for a quick recap:
- work within an early http.middleware service.
- ensure a consistent order for the query parameters.
- ignore query parameters based on an allow/disallow list.
- read this allow/disallow list set by the routing definition, gathered by a Routing listener service into KV records for quick checks.
- perform a single (1 per request?) preemptive (DB table size [better IMO] OR rows count) check before inserting an item into the cache, and (ignore until the next cron run OR prune) if full, instead of pruning AFTER the limit was exceeded.
- partial pruning using a popularity index, instead of the current max rows approach.Maybe some of them have been addressed in the recent core releases.