Use Symfony PhpDumper instead of a serialized array container structure

I think @chx's idea from #2497243-81: Replace Symfony container with a Drupal one, stored in cache is still worth exploring, mostly because of PhpStorage's inherent problems with slow shared filesystems.

That would still require each site builder/owner to know and think about this stuff, while the stream wrapper idea works pretty much out of the box :)

How does it compare with the other issue optimizations?

Could this use MtimeProtectedFileStorage instead of the manual hash validation or was that already firmly rejected?

Checking the mtime over nfs would likely have some overhead but it possibly might not be worse than a database query.

+1 to #15 - the change makes sense but it is not really connected to this.

Re: #3 and #13, reading through the Symfony phpdumper code at

https://github.com/symfony/dependency-injection/blob/8.1/Dumper/PhpDumpe...

I see that at line 125 is the $as_files option, 'To split the container in several files'.

Did the Drupal 8 implementation of PhpDumper split the container into multiple files? Would that option be used/ need to be used in this swap back to PhpDumper?

Could it impact performance?

@oily I can't see any reason to split into multiple files if we have to load it all on every request anyway, it would just mean more file i/o, is there a specific reason you're asking about this?

@longwave OK thanks for explaining, I think we should add some of that to inline comments in DrupalKernel::initializeContainer() though.

One question - do we need to add test coverage for having a container cache key, but no respective file on disk (file got manually deleted, database got backed up and moved to a different environment etc.)?

Didn't review yet, just saw the comment from @catch in #3583040: Cache the container definition in APCu

> (no unserialize at all even from APCu)

not sure if that refers to the unserialize of the whole thing or the unserialize of each definition that we do. I quickly looked into the definition unserialize bit when testing redis compression and whether that's worth doing with that, but not doing it resulted in a fairly significant memory increase on cached pages, so we should definitely test that when making changes here.

not sure if that refers to the unserialize of the whole thing

I meant the unserialize of the whole thing in that comment, e.g. of the cache item itself.

https://symfony.com/doc/current/performance.html#performance-service-con... seems relevant here. I've tested what happens and we're definitely using a single file. I have concerns about the container for a large Drupal site being bigger than what opcache can handle. We'll need to be careful with that.

Things of interest... installing via drush does not result in the container being dumped. neither does running drush cr... however once you visit the site the container is dumped and then drush cr does generate a new container. Interesting. If you then remove the container files and run drush cr it's not regenerated until you visit the site. If you diff the container before and after the drush cr you will see something like:

diff drupal-container.php sites/default/files/php/service_container/DrupalContainer_66a41afb265ef82b609f316dc9479511/4MlDfuLTpuuuMg3IvPnwFpJghyHXu83UGMdXKHMNLJs.php       Thu 16 Apr 10:41:36 2026
15c15
< class DrupalContainer_2d904733285eeb41ec2f60e50829b1fb extends \Drupal\Core\DependencyInjection\DumpedContainer
---
> class DrupalContainer_66a41afb265ef82b609f316dc9479511 extends \Drupal\Core\DependencyInjection\DumpedContainer
507a508
>             'logger.drupaltodrush' => 'getLogger_DrupaltodrushService',
7184a7186,7195
>     }
>
>     /**
>      * Gets the public 'logger.drupaltodrush' shared service.
>      *
>      * @return \Drush\Log\DrushLog
>      */
>     protected static function getLogger_DrupaltodrushService($container)
>     {
>         return $container->services['logger.drupaltodrush'] = new \Drush\Log\DrushLog(($container->services['logger.log_message_parser'] ??= new \Drupal\Core\Logger\LogMessageParser()));
7208a7220
>         $instance->addLogger(($container->services['logger.drupaltodrush'] ?? self::getLogger_DrupaltodrushService($container)), 0);

So this drush service bleeding in to the container on drush cr is not a new issue - happens with the db backed container too...

What's super interesting is if you do two drush cr one after another the container is completely removed from the file system.

Note that going to the performance page and flushing the caches via the UI does regenerate the container as a fresh file each time.

Couple more things to note. If I switch to this branch on a live site and visit a page I get

Warning: Array to string conversion in Drupal\Core\DrupalKernel->initializeContainer() (line 976 of core/lib/Drupal/Core/DrupalKernel.php).
Drupal\Core\DrupalKernel->initializeContainer() (Line: 473)
Drupal\Core\DrupalKernel->boot() (Line: 686)
Drupal\Core\DrupalKernel->handle() (Line: 19)

The disappearing container after two drush cr's only happens with this branch not on HEAD.

This should fix @alexpott's problem. It should be very fast, but I'm not sure if we want it in the critical path:

975 -        if ($sentinel && $hash = $sentinel->data) {                                                                                                                             
975 +        if ($sentinel && is_string($sentinel->data) && $hash = $sentinel->data) {   

Alright, I just committed it.

Re opcache size: I measured on Umami with DDEV. The compiled container is 703KB on disk and takes 1609KB in opcache.

I believe this is actually more memory efficient than the current serialized approach: today, every FPM worker unserializes the container definition into its own heap memory. The opcache is shared across all workers.

The main scenario where opcache size could be a concern is multisite?

I think with container size @alexpott meant https://www.php.net/manual/en/opcache.configuration.php#ini.opcache.max-...

However the default for that is 0 (unlimited) so it's probably OK? And we could add a hook_requirements() check.

There's the risk of the opcache filling up but we have plenty of open issues that can help with that (persistent discovery caches, dropping annotations support so the opcache can strip comments etc.).

For the type issue can we add something extra to the container cache key maybe? But also is_string() is fine too.

Re: #19 @catch

I can't see any reason to split into multiple files if we have to load it all on every request anyway, it would just mean more file i/o, is there a specific reason you're asking about this?

I was not sure if the option had been considered. I would have thought it best not to use the option unless it were needed, so agree with you on that. @longwave sees it as intended (in certain contexts) as a way of improving performance.

Re: #22 Interesting.. That option stood out for me. Was just wondering if it might be relevant. As a possible future enhancement makes sense.

I've pushed an alternate fix for #24 without the extra function check - just a slight tweak to the cache key - which also makes it more truthful - and we can avoid the extra part of the if.

@catch is correct I'm concerned about the impact of this when the container is huge - umami does not have a lot of contrib installed. I've seen Drupal sites with tonnes of modules installed and I'm wondering whether we should be concerned.

I know its a bit off topic but since we are looking towards Symfony for performance enhancements and I have been experimenting for 6 months with the high performance symfony production version symfony docker: https://github.com/dunglas/symfony-docker which is based on FrankenPHP..

https://frankenphp.dev/docs/worker/ ie:

"Boot your application once and keep it in memory. FrankenPHP will handle incoming requests in a few milliseconds."

Symfony-docker serves as a dockerised local dev environment but the images can be rebuilt for production and deployed to production. That removes the dev tools like XDebug and optimises the PHP config etc DDEV could do the same for Drupal?

Pushed up an idea of how to fix the problem with app root and site path... we can add them to the container cache key so if they change we'll build a fresh container.

Still need to work out what's going on with drush cr and the container removal.

Okay I've fixed the code so that it does rebuild and save the container when drush cr is used. Setting to needs review because I think all the things I've spotted have been fixed.

Maybe we can test after installing a couple hundred modules even if it's just manual.

Is #3585294: Convert bootstrap container from array to PHP exactly the same as the change here for the bootstrap container? I'm guessing the idea is to get that issue in first to have a smaller diff here, but wanted to double check.

Added a test to prove that adding the site path to the cache key works. The test passes on HEAD and on this MR but fails if you remove the changes to the \Drupal\Core\DrupalKernel::getContainerCacheKey().

Just need to work out how to add test coverage for the issue revealed by drush cr.

@catch is correct I'm concerned about the impact of this when the container is huge - umami does not have a lot of contrib installed. I've seen Drupal sites with tonnes of modules installed and I'm wondering whether we should be concerned.

Thought about this a bit:

database - can handle large objects, but noticeably slows down as they get bigger
APCu - can handle it, as long as the total memory allocated is enough (which a large container won't help with, but not worse than other things we put in there like thousands of config translations)
memcache - by default, can't handle anything over 1mb
redis - can handle it

opcache - by default can handle it, unless you set opcache.max_file_size too low

So I feel like it'll be fine, at least relative to the other options we have, as long as PHP isn't configured to break it, it would be great if someone can apply this diff to a moderately large Drupal install and check though.

Yes, I extracted the change from here and moved it over there, but the basic idea is the same: the container becomes opcacheable PHP instead of an array that needs parsing at runtime. The issues can land in either order, they cover the same ground but the two containers are independent.

That makes sense, but should we drop it from the MR here in that case?

edit: I see that's already been done, sorry.

Decided to check some of the larger PHP files that we already have in core so we know whether we're going to massively increase the maximum size of the largest PHP file. I did Drupal 10 and Drupal 7 because Drupal 11/12 OOP hooks means we've got a lot less massive files in general.

Didn't do anything special to find big files, just checked ones I already knew would be on the bigger end of what's in core with ls -lh

Drupal 10:

87K Apr 17 15:06 system.install
 62K Apr 17 15:06 system.module
73K Apr 17 15:06 ViewExecutable.php
109K Apr 17 15:06 install.core.inc

Drupal 7:

143K Feb 20  2025 system.module
315K Feb 20  2025 includes/common.inc
114K Feb 20  2025 includes/theme.inc
199K Feb 20  2025 form.inc

So common.inc in Drupal 7, which is loaded on every request, is 315k, and while Drupal 7 is unsupported we know a couple of hundred thousand or more sites run it in production with opcache.

The physical size of the file on disk doesn't necessarily map to opcode size but I don't know how to get that for a single file.

Doing a quick size test.

I enabled every core and about 30 test modules
This branch container size is 878K on disk, only one container file is printed.
Two entries in cache_container

container_hash:prod:7f4f387ef967c9e1:/var/www/ 32B
container_hash:prod:7f4f387ef967c9e1:/var/www/html:sites/default:722670320:Linux:a:1:{i:0;s:40:"/var/www/html/sites/default/services.yml";} 32B

Not apples to apples, but I get this in the db on main for same modules:

service_container:prod:7f4f387ef967c9e1:2030988678:Linux:a:1:{i:0;s:40:"/var/www/html/sites/default/services.yml";} 602.8KiB
service_container:prod:7f4f387ef967c9e1:2088506545:Linux:a:1:{i:0;s:40:"/var/www/html/sites/default/services.yml";} 602.8KiB

Also, with standard profile and no additional modules the container size on disk for this branch is: 635K
Standard profile on main db entries are 439.3KiB

I've added a requirements check to ensure that if you have opcache enabled the container is in it. I think this will help any sites which have really fined tuned their opcache settings get it right.

Which actually brings me to an interesting thing. When we invalidate the container we rebuild it and the write it to mtime protected storeage which even if it is exactly the same container will result in the file name changing. Which means a new entry in the opcache. I wonder if it is worth trying to do this in a better way.

I've addressed #47 and it is tested... this should result in quicker cache rebuilds too! No unnecessary container dumps when nothing changes... and the opcache will still work.

I tested the opcache accumulation problem on DDEV with Umami. Each invalidateContainer() + rebuild added a new ~1.6MB opcache entry even when the container content was identical. After 3 rebuilds I had 4 stale entries (6.3MB) in opcache with only 1 file on disk. With opcache.validate_timestamps=0, these entries are never evicted.

I was working on a fix (skip save when hash is unchanged, remove deleteAll() from invalidateContainer()) but I see @alexpott just pushed essentially the same approach. Looks good!

https://symfony.com/doc/6.4/performance.html#dump-the-service-container-...

"Symfony compiles the service container into multiple small files by default."

Might be an obvious question, but does our implementation of PHPDumper compile the service container into a single file?

Here's a performance analysis of cache clearing done by Claude

70311491b27 is the commit before the fix to not delete the container if the hash does not change.

The test was clear the cache 5 times and do it 20 times while recording the time taken using drush.

  ┌────────────────┬──────────────┬────────┬────────────┐
  │      Ref       │ Trimmed Mean │ StdDev │   95% CI   │
  ├────────────────┼──────────────┼────────┼────────────┤
  │ Current branch │ 651ms        │ 15ms   │ [644, 658] │
  ├────────────────┼──────────────┼────────┼────────────┤
  │ 70311491b27    │ 684ms        │ 13ms   │ [678, 690] │
  ├────────────────┼──────────────┼────────┼────────────┤
  │ Main           │ 650ms        │ 13ms   │ [644, 656] │
  └────────────────┴──────────────┴────────┴────────────┘

  Statistical comparisons (Welch's t-test)

  ┌───────────────────────────────┬─────────────────┬─────────┬──────────────┐
  │          Comparison           │      Diff       │ p-value │ Significant? │
  ├───────────────────────────────┼─────────────────┼─────────┼──────────────┤
  │ Current branch vs Main        │ +1.2ms (+0.2%)  │ 0.808   │ No           │
  ├───────────────────────────────┼─────────────────┼─────────┼──────────────┤
  │ 70311491b27 vs Main           │ +34.1ms (+5.2%) │ <0.0001 │ Yes          │
  ├───────────────────────────────┼─────────────────┼─────────┼──────────────┤
  │ Current branch vs 70311491b27 │ -32.9ms (-4.8%) │ <0.0001 │ Yes          │
  └───────────────────────────────┴─────────────────┴─────────┴──────────────┘

  Interpretation

  - Current branch is statistically identical to main (p=0.81, ~1ms difference -- pure noise).
  - Commit 70311491b27 is ~34ms slower than both main and the current branch, and this difference is highly significant (p<0.0001). That commit likely introduced a small regression that was
  fixed in subsequent commits on the branch.

Re #50 if it was going to multiple files it wouldn't work :) - but you're probably correct that we want to ensure this.

Only remaining question I have is NFS, I have clients that use a shared nfs for multiple web heads, will this have an impact compared with a db container?

@nicxvan I think we also need to think about multiple web-heads... and what happens when a rebuild occurs. ie. How do we handle races to rebuild the container.

Feels like there's a higher chance of a race condition and stampedes with the container because it's so early in the request and guaranteed to be needed on every request. Also takes longer to build than a twig template.

Whereas a lot of twig templates end up behind render cache and there will be more variation in when requests reach the point of generating them, even during a stampede since it tends to be one of the last things that happens during a request. Also very hard to reproduce outside of production environments, although usually we do get reports of things like this eventually.

Whether there actually is one though is a different matter, it might be fine and it's going to be hard to rule in or out.

I think it depends what we're concerned about most - is it multiple requests building the container unnecessarily? Or is it that we could end up in some kind of death spiral where the mtime storage or cache key keeps getting invalidated causing another rebuild? Haven't reviewed mtime storage for a while or the latest code here to have a good grasp of what could go wrong.

The only mitigation I can think of is adding a lock service to the bootstrap container and then putting the container write inside a lock. Although the latest changes seem good to reduce repeated container building when the result is the same.

But then what do we do with requests that don't acquire the lock - wait for a bit then build the container without writing it if it's not ready yet? Because it's quite expensive to build there's also the risk of a lock stampede too.

@nicxvan I think NFS is going to come down to how expensive an mtime check is over nfs and also whether opcache suffers at all. However per @Dries apcu issue and profiling in there, even a small container is a solid couple of milliseconds to get from the database cache and larger ones could take 5ms or more, so there is probably some room for things to be comparable or better rather than worse.

@longwave leaving support for the array container would help with the container_base_class change too. And then we could deprecate the array container in Drupal 13. We could install new sites using the php dumper and leave existing site on the array container and put something on the requirements in the issue that does the deprecation.

We could install new sites using the php dumper and leave existing site on the array container and put something on the requirements in the issue that does the deprecation.

We could do this for 11.x, then switch to the dumper container by default for all Drupal 12 sites with settings.php as an opt-out back to the array container maybe? Treat the setting being NULL as FALSE in 11.x and TRUE in 12.x.

Assuming this gets into 11.4 we'll have at least a couple of months of data to make a final decision on that for 12.x too.

@catch we don't even need a new setting we can use the container_base_class setting :) - I've just pushed a commit that implements this with the help of claude.

More NFS thoughts, apart from potential race conditions/stampedes feels like there's two things that could go wrong for general performance:

1. The baseline performance might be slow - by default there'll be an mtime check from mtime protected storage, then another one from opcache, then the class itself should come from opcache hopefully. This is probably not going to be slower than getting the entire container array out of the database but we're not sure.

2. If NFS performance gets degraded - heavy file writing due to a bulk file import or whatever else, could this be worse than database performance getting degraded under load. We would guess not due to twig templates but again can't be entirely sure.

For high traffic sites, there might be a way around for all of these:

We can suggest a set-up where raw PHP files are used instead of mtimeprotected storage, in a directory like vendor/drupal/container outside the webroot that will be read only on production.

This would allow for committing the PHP container to the codebase - either the active code base or in a deployment repo in a build step.

At least the old and new production containers would need to be in the code base, so that the site can smoothly switch from one to the other.

This would mean no NFS and no file writing.

Things that could go wrong:
- installing a module in a hook_update_N() or updating certain config can result in an intermediate container, e.g. different containers before, during, and after a deployment not only before and after. For the 'during' containers it might be fine if they never find their way onto disk, but not sure how to allow for that situation.

- need to make sure that sites can have this setup, but also use mtimeprotectedstorage for twig templates etc.

I don't think we need to document that here but it would be good to be relatively confident that it's going to be possible, and then open an issue to document the concept somewhere.

Re: #63

...sites that know what they are doing could even ship their runtime container in git...

When you deploy to production you will often be adding/ removing/ editing services. So not sure about storing and deploying the container in git. Would it be better to run a script that regenerates the container (once) on each deployment?

I've taken #63 and implemented with the help of Claude something along the lines that I think @longwave is suggesting.

We won't be able to have a single container in git unless we fall back to container builder when the container isn't on the filesystem and expect that to work until updates and config import are finished. The main problem I see with that is that both maintenance mode and the page cache require the container so it is potentially a long window of a lot of requests having to build a container. My idea in #62 would also have that problem for a shorter window though if there are two or three container keys due to different module installs during a single deployment. Might be worth opening a follow-up nowish to discuss this more.

I'm super happy with where this now. I've updated the issue summary with help from Claude to reflect the current MR.

Re: #66

We won't be able to have a single container in git...

and #63

...sites that know what they are doing...

Could some of the container operations discussed in #63 and #66 be tested out in a script in core/scripts that gathers info on the productions site and reports back any important info and recommendations regarding the container? No doubt would be in a follow-up. But could be an interim measure that '...sites that know what they are doing...' could take advantage of without imposing code solutions until the fruits of this issue have been in flight for a few months?..

It seems that at least some of the existing core scripts are Symfony commands. Which is pretty handy since the Symfony docs will help

'...sites that know what they are doing...' can thus expand on any ideas they get from scripts produced by Drupal core team.

Any scripts could be targetted to be run on deployment to production. They could issue warning for example if the latest changes to files might lead to problem with rebuild of or size of container..

Such script(s) would not need to cover all bases, more like draw attention to the complexity of the container, its importance for stable productions sites and to encourage more detailed scripts to be developed by devops/ pipeline staff.

I've renamed DumpedContainer to PhpContainer based on @longwave's comment

All containers are dumped - we still dump the array for the old format - so what about PhpContainer? Matches PhpDumper and perhaps we can keep the name if/when we remove the array-based Container

After doing this because I think it is a better name I had the thought "Well all containers are going to be PHP containers too... what we really mean here is a php file backed container." FWIW I think PhpContainer is fine but I thought I'd bring this up in case anyone has a great idea and also because it made me smile.

Opened #3585729: [PP-1] Document how to ship the dependency container in code for #62

Symfony and Laravel store their compiled containers as plain PHP files without MTimeProtectedFileStorage.

Could we do the same here, or is there a specific threat model that requires mtime protection for the container? Asking because we may not need this requirement.

We already have the hash for cache invalidation purposes.

For tamper detection, if an attacker has write access, there is all kinds of damage they can do already, regardless of the mtime protection.

Minor: PhpContainer::__sleep() uses assert() which is disabled in production. Should this be a throw?

Btw __sleep() must be replaced as this is a new code #3548971: Deal with PHP 8.5 deprecation of __sleep()/__wakeup()

Did some performance testing using apache workbench. On a node page without page cache or dynamic page cache enabled and the render cache set to a null backend.

Main

Server Software:        Apache/2.4.66
Server Hostname:        drupal8alt.test
Server Port:            80

Document Path:          /node/1
Document Length:        16877 bytes

Concurrency Level:      4
Time taken for tests:   10.089 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      17844000 bytes
HTML transferred:       16877000 bytes
Requests per second:    99.12 [#/sec] (mean)
Time per request:       40.354 [ms] (mean)
Time per request:       10.089 [ms] (mean, across all concurrent requests)
Transfer rate:          1727.29 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       0
Processing:    37   40   3.7     39     144
Waiting:       36   39   3.7     39     143
Total:         37   40   3.7     40     144

Percentage of the requests served within a certain time (ms)
  50%     40
  66%     40
  75%     40
  80%     40
  90%     41
  95%     42
  98%     44
  99%     46
 100%    144 (longest request)

MR

Server Software:        Apache/2.4.66
Server Hostname:        drupal8alt.test
Server Port:            80

Document Path:          /node/1
Document Length:        16877 bytes

Concurrency Level:      4
Time taken for tests:   9.741 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      17844000 bytes
HTML transferred:       16877000 bytes
Requests per second:    102.66 [#/sec] (mean)
Time per request:       38.962 [ms] (mean)
Time per request:       9.741 [ms] (mean, across all concurrent requests)
Transfer rate:          1789.00 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       0
Processing:    34   38   4.1     38     138
Waiting:       34   38   4.0     37     137
Total:         34   38   4.1     38     139

Percentage of the requests served within a certain time (ms)
  50%     38
  66%     38
  75%     39
  80%     39
  90%     41
  95%     43
  98%     47
  99%     52
 100%    139 (longest request)

I repeated the tests a few times and even on this very simple page with not that many services involved there is a measurable and consistent speed up.

With page cache...

What gets really really exciting is when you have page cache enabled...

Main

Server Software:        Apache/2.4.66
Server Hostname:        drupal8alt.test
Server Port:            80

Document Path:          /node/1
Document Length:        16877 bytes

Concurrency Level:      4
Time taken for tests:   7.626 seconds
Complete requests:      10000
Failed requests:        0
Total transferred:      178950000 bytes
HTML transferred:       168770000 bytes
Requests per second:    1311.26 [#/sec] (mean)
Time per request:       3.051 [ms] (mean)
Time per request:       0.763 [ms] (mean, across all concurrent requests)
Transfer rate:          22914.97 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.2      0      11
Processing:     2    3   0.6      3      13
Waiting:        2    3   0.6      3      13
Total:          2    3   0.6      3      14

Percentage of the requests served within a certain time (ms)
  50%      3
  66%      3
  75%      3
  80%      3
  90%      3
  95%      4
  98%      4
  99%      5
 100%     14 (longest request)

MR

Server Software:        Apache/2.4.66
Server Hostname:        drupal8alt.test
Server Port:            80

Document Path:          /node/1
Document Length:        16877 bytes

Concurrency Level:      4
Time taken for tests:   4.040 seconds
Complete requests:      10000
Failed requests:        0
Total transferred:      178950000 bytes
HTML transferred:       168770000 bytes
Requests per second:    2475.54 [#/sec] (mean)
Time per request:       1.616 [ms] (mean)
Time per request:       0.404 [ms] (mean, across all concurrent requests)
Transfer rate:          43261.53 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       9
Processing:     1    1   0.5      1      17
Waiting:        1    1   0.5      1      16
Total:          1    2   0.5      2      17

Percentage of the requests served within a certain time (ms)
  50%      2
  66%      2
  75%      2
  80%      2
  90%      2
  95%      2
  98%      2
  99%      2
 100%     17 (longest request)

I've created 3 change records with help from claude. They target different audiences:

• https://www.drupal.org/node/3585820 is for everyone and tells people how to use a PHP dumped container
• https://www.drupal.org/node/3585822 is about the changes to the bootstrap container and what to do if you overrode it
• https://www.drupal.org/node/3585642 is for people who have custom DrupalKernels

Removing container_storage_class from the issue summary - it no longer exists.

Added info about the bootstrap container changes to the issue summary.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

So I've set up a docker compose file to test nfs plus multiple web heads. With the current MR we hit races on both the multiple web heads and in a single web head. This can result in the number of compiled containers growing and growing and growing.

Discussed with @berdir, @longwave, and @kingdutch - who made great suggestions that have resulted in exploring moving the containers to the system temp directory - still using mtime protection. Also we found that even with moving to a local file system we created multiple contains because most web servers have multiple workers which also get in a race. Therefore we need to implement some sort of locking mechanism.

Here's how I set up the mulitwebhead docker environment... https://github.com/alexpott/multiwebheads

It wasn't clear to me if this was being done only for performance improvements or to fix other issues. I know there were some performance tests done. Can we add the expected performance improvements to the issue summary?

@kim.pepper this is being done for multiple reasons:

• Performance
• Get access to Symfony's container stuff like env var backed parameters without having to implement it all ourselves - eg. #3249970]

I've added this to the issue summary as rationale section.