Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
On incoming requests, we check resolve aliases to paths.
This runs a query (which is very poor for the MySQL query cache) on every request to check if the path matches a path alias.
If there are no path aliases, the query still runs.
Proposed resolution
Store whether we have any path aliases or not somewhere. (in the path alias whitelist in a magic key? a separate cache item?). If there are no aliases at all, we could compeletely skip the lookup. Want to ensure there isn't an undue cost for sites that do have path aliases.
Remaining tasks
Figure out a solution and patch it.
Comments
Comment #1
dawehnerThe path alias whitelist is not possible right, because we need to run the path alias conversion before we get to the system path, and just by having that we can get that list of path aliases.
I guess we should need an extra cache entry.
For a while I thought that we could figure out how many path aliases we have on container build time and then skip registering those services in total, but I realized that this was BS.
Another idea I had in mind is that in D8, unless d7, we could actually move every functionality of the path alias system into its own module, which would allow you to simply disable the entire functionality, move the inbound/outbound processor to path module, as well the alias manager, or at least the fact that we register those services.
Comment #2
catchVery good point.
Large-ish change but possibly the cleanest. Although we already have path.module so it'd either need to move in there or could get confusing with names.
Comment #3
catchSorry this actually isn't such a good point.
There are two things we do to reduce queries:
1. A whitelist of system path roots (so node, user, admin etc.) where there is at least one alias assigned to a system path matching that. This is global for the whole site so it's available where we'd need it.
2. A pre-load cache of system paths for outbound alias look-ups - this is per system-path and not available, so we can't use it here.
For #1 that's quite possible to use. The trick though is we'd either need to add a method, or use a magic key like AliasWhitelistManager::HAS_ANY_ALIAS and handle that differently in resolveCacheMiss() - then we do a SELECT 1 FROM {path_alias} LIMIT 0, 1 if it's not set. That would save the additional cache entry but don't love the magic key.
Comment #4
dawehnerSo we now cache things per incoming path already, so I think we don't run this query too often.
@catch
Do you think our routing level caching is enough?
Comment #5
catch@dawehner we could skip the query and the cache for sites with no aliases. So if we care about those sites, it'd be an improvement for them.
Comment #6
dawehnerHonestly, that sounds a bit like an edge case usecase for me ... those could use a contrib module which swaps out the path services to do just nothing.
Comment #7
catchThat's reasonable. Or we could look at defaulting to a null service in core, then letting path/path alias wire it up.
Comment #8
dawehnerThis would be an API break, because well, you can use already path aliases via API and then enable path module to deal with it. Path is afaik more of a path_ui module at this point.
Comment #9
catchYes it'd be an API break, just that might be something to do in 9.x.
Comment #10
catchWell there might be more alias-free websites than we think - i.e. something which only does REST. Moving to 8.1.x for now.
Comment #24
quietone CreditAttribution: quietone at PreviousNext commentedI have not triaged this issue, I just notice that it is no longer postponed.
Comment #25
BerdirI'm going ahead and closing this as outdated.
AliasManager is part of the path_alias module now. If you do not want aliases at all, you can disable that module and then no alias lookups happen, ever.