FEATURE: Make cache lifetime of routing caches configurable

[mficzel]

Is there an existing issue for this?

• I have searched the existing issues

Description

The routing caches currently have no lifetime and thus all entries live forever unless someone configures a default lifetime.
This is generally fine but some routes may still require different lifetimes than others. It would be great to configure the lifetime for the routing and resolve cache for each route individually.

Possible Solution

Add the options routeCacheLifetime and resolveCacheLifetime to the routing configuration

-
  name: 'Some route'
  ...
  cacheLifetime: null|int(default null)

This is a based on the issue #1426 but uses a different approach

[sorenmalling]

To clarify: How is this different from

  backendOptions:
    defaultLifetime: 60

from Cahces.yaml

and setting that on

Flow_Mvc_Routing_Route:
  backend: Neos\Cache\Backend\FileBackend
Flow_Mvc_Routing_Resolve:
  frontend: Neos\Cache\Frontend\VariableFrontend
  backend: Neos\Cache\Backend\FileBackend

[sorenmalling]

This is generally fine but some routes may still require different lifetimes than others

What is a use case for this and what is the difference between routeCacheLifetime and resolveCacheLifetime?

[mficzel]

The difference to the defaultLifetime is that this is configured for a specific route and not the whole cache.
Makes sense for routes that might not be there forever or that encode fluctuating entries in pathes.

[bwaidelich]

As discussed in other places, I'm a little skeptical of this approach since it mainly targets the symptoms.
Parsing and iterating through all routes is a very "expensive" process.
If you happen to have one (let alone hundreds) of uncached links on one page, this can have massive impact on performance. Especially on high traffic sites where this factor could hit multiple requests at once.

To recap: Root cause for the cache flooding is:

• overly use of route arguments (where you actually want to use query parameters, for example in search forms)
• the current cache implementation that creates an entry for every route argument combination (no matter whether the corresponding value ends up in the URI path or query parameters)

I think we could contain the issue by:

• good documentation of how and when to use query parameters
• improved Fusion prototypes (that allow easy usage of query params) and a reworked UriBuilder
• and, more related to this issue: A better cache implementation that only stores a single entry for the route argument keys

[mficzel]

The weirdest case i know of is a callback url that had to encode values in the path (by route) because some external service appended external data always with a question mark and did not respect existing query parameters. Clearly buggy but nothing i could change.

Offcourse this is extreme but whenever external identifiers somehow are handled in a path it may make sense to control the caching time for a route separately from the global defaultLifetime. Ideally one could also define special cache-tags for such routes.

I totally agree that this is not the general solution for routing cache overflow but more a tool to handle edge cases.