When we converted Drupal 7 to the Symfony routing system we made fast 404s only do stuff on exception - i.e. when routing has determined there is a 404 already. This makes the system/files part of the suggested config in default.settings.php pointless but also it means that we have to do routing for paths that we would previously (in Drupal 7) not have done.
Locally fast 404s are not fast for me. In fact they are slower. Compare:
Document Path: /something
Document Length: 23112 bytes
Concurrency Level: 1
Time taken for tests: 4.321 seconds
Complete requests: 1000
Failed requests: 0
Non-2xx responses: 1000
Total transferred: 24727000 bytes
HTML transferred: 23112000 bytes
Requests per second: 231.42 [#/sec] (mean)
Time per request: 4.321 [ms] (mean)
Time per request: 4.321 [ms] (mean, across all concurrent requests)
Transfer rate: 5588.09 [Kbytes/sec] received
Document Path: /something.jpg
Document Length: 193 bytes
Concurrency Level: 1
Time taken for tests: 6.423 seconds
Complete requests: 1000
Failed requests: 0
Non-2xx responses: 1000
Total transferred: 704000 bytes
HTML transferred: 193000 bytes
Requests per second: 155.68 [#/sec] (mean)
Time per request: 6.423 [ms] (mean)
Time per request: 6.423 [ms] (mean, across all concurrent requests)
Transfer rate: 107.03 [Kbytes/sec] received
Emit a cacheable exception from Fast404ExceptionHtmlSubscriber so that it can be cached in the same way as other 404s.
None
Fast404ExceptionHtmlSubscriber now takes the cache_tags.invalidator service instead of http_kernel service.
Fast 404s are cacheable in the page cache and work the same way as other 404s.
It is no longer necessary or recommended to configure fast 404s in settings.php → .
Fixed
9.5
Last updated
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
If anyone else is using the Search 404 module, I think this change should be considered over there. If it's no more recommended to use fast_404 in settings.php it might mean that by removing these settings, all those 404's are handled by Search 404, resulting in many database queries for the missing files.
That might be a heavy performance trap? See 🐛 Exclude fast_404 paths and file extensions by default (Performance) Postponed: needs info