[DI] Generate one file per service factory #23678

nicolas-grekas · 2017-07-26T10:10:29Z

Q	A
Branch?	master
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	no
Tests pass?	WIP
Fixed tickets	-
License	MIT
Doc PR	-

With this PR, when the new "as_files" option is set on the dumper, it generates an array of files, one per service factory, private or public ones. That's it, nothing else but implementation details.

The benefit should be exactly the same as autoload for class definitions: only the service factories required for the current request are being loaded.

On the technical background, you may wonder if this is relevant with OPcache. If you inspected serious apps with Blackfire, you may have noticed that the container file can take some significant time+memory when the number of services grow. The reason is that even if the class is pre-compiled in shared memory by OPcache, its opcode array still needs to be copied in the memory of the current request. That takes time, and memory.

This PR builds also on static arrays and interned strings to lower the CPU+RAM footprint of the container to the strict minimum.

Yes, doing a require, even an OPcached one, is slower than running an already loaded method. But that number of require/method is low (one per instantiated service, no more). In the end, the dead code elimination provided here wins.

Of course, if anyone can help provide actual numbers, that'd be really awesome.

First bench, front page of the standard edition:

profiler shows that memory goes from 4MB to 2MB and no eye-visible diff in wall time
ab -n 100 goes from 1.55s to 1.50s
blackfire measures -1% in wall time and -20% in memory

Of course, the page is so thin that measuring the effect of the patch is hard. Yet, all measuring tools go in the same direction, Yay! If the benefit is measurable for a simple app, the benefit for real apps is going to be much higher. Looks like the container can now scale with a growing number of services :)

When the "as_files" flag is not set, the same code as before is generated. I've updated the Kernel to set that flag in non-debug envs, so that prod has the optimized code loading strategy, and devs can still open a single file to inspect the factories easily.

nicolas-grekas · 2017-07-26T10:13:04Z

src/Symfony/Bridge/ProxyManager/LazyProxy/PhpDumper/ProxyDumper.php

        }

        if (null === $methodName) {
            throw new \InvalidArgumentException(sprintf('Missing name of method to call to construct the service "%s".', $id));
        }

+        $factoryCall = sprintf($definition->isPublic() || !method_exists(ContainerBuilder::class, 'addClassResource') ? '$container->%s(false)' : '%s::create($container, false)', $methodName);


passing the factory class instead of the method name may need to be done another way to preserve BC

fixed via #23693

nicolas-grekas · 2017-07-26T10:14:31Z

src/Symfony/Component/DependencyInjection/Tests/Fixtures/php/services9_compiled.php

@@ -456,3 +498,20 @@ protected function getDefaultParameters()
        );
    }
 }
+
+final class ProjectServiceContainer_FactorySimpleService extends ProjectServiceContainer


here is the kind of class that this generates

javiereguiluz · 2017-07-26T11:10:27Z

About this:

I'm playing with the idea of splitting the container class in several files.

I can see added complexity in three ways:

The logic that generates the compiled container will be more complex.
Finding a problem in the compiled container will be more complex, because there's no longer one file to look for but a lot.
Performance should be worse. It's just a guess, but having multiple PHP files instead of 1 PHP file should be slower for some things (PHP parsing?, autoloading?)

So, which are the benefits that I'm missing i this proposal? Thanks!

nicolas-grekas · 2017-07-26T14:14:48Z

Performance should be worse. It's just a guess

It's a guess, so if you're wrong, you have your benefit, there is no other.
As written: "to be proved useful". Only a bench will tell.
We already removed classes.php because having everything in one file proved being slower in fact.
I'd like to try if that applies to the container also. Might benefit large ones more than others.

robfrawley · 2017-07-26T16:40:34Z

Sounds interesting. Is this PR functional? I have access to a few fairly large (monolithic) applications I'd be happy to test this against.

nicolas-grekas · 2017-07-27T13:30:03Z

@robfrawley not ready yet, I'll report back :)

…umperInterface::getProxyFactoryCode() (nicolas-grekas) This PR was merged into the 3.4 branch. Discussion ---------- [DI][ProxyManager] Pass the factory code to execute to DumperInterface::getProxyFactoryCode() | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | yes | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - Passing the full code to call the factory is more flexible, as spotted while working on #23678. Commits ------- 0754617 [DI][ProxyManager] Pass the factory code to execute to DumperInterface::getProxyFactoryCode()

nicolas-grekas · 2017-07-31T07:56:37Z

@ogizanagi should be fixed (lazy proxies are not split anymore because that needs more work - another PR maybe.)

…ices

ogizanagi · 2017-08-01T19:24:19Z

So I tried in a real-life app, and here are some new blackfire profile comparisons:

A simple login page: https://blackfire.io/profiles/compare/09df978b-1da9-47fa-a1ba-64fd5b153192/graph
An EasyAdmin edit page: https://blackfire.io/profiles/compare/cdeffc79-6585-4f4a-aacc-0ba3d6fff5ff/graph
An api endpoint: https://blackfire.io/profiles/compare/c8b96f36-15cf-4c1f-b5f6-63b355782eff/graph

No significative diff at all it seems :/

In addition, note the var/cache/prod dir also grew from 2.9M to 8.5M (for ~270 services non-inlined services).

nicolas-grekas · 2017-08-01T19:51:45Z

3.4 or 4.0? What about testing using ab?

ogizanagi · 2017-08-01T20:24:11Z

Using Symfony 4.0.

Tests using ab do not show any noteworthy difference either.

nicolas-grekas · 2017-08-02T11:33:07Z

Profiling Blackfire itself, which has a pretty serious container, I consistently get slightly better results with the patch enabled (using patch in#23741 to be compatible with it.)

A Blackfire profile doesn't notice any conclusive wall time improvement, but on the memory side, the reduction is consistent:

Using ab, things are more interesting: I go from 104 req/s. to 108 req/s. Not tremendous, but still nice to have have a +4% perf boost just by upgrading.

jpauli · 2017-08-03T08:25:16Z

OPCache needs to copy from SHM to current process local memory all the classes it parses.
All the classes, means all their constants, static attributes, declared attributes, functions (op_arrays), used traits, and rebind the class (re-traverse the inheritence tree).

This process is highly optimized in OPCache, we even designed an SSE2 SIMD process for part of such a work (https://github.com/php/php-src/blob/PHP-7.1/ext/opcache/zend_accelerator_util_funcs.c#L605)

But it will still eats some little CPU cycles, and above all, will eat "a lot" of memory because a class is really a heavy stuff into PHP in term of memory footprint (much more than an object).

All this process is detailed in an article I once wrote (targeting PHP 5) at http://jpauli.github.io/2015/03/05/opcache.html

Source code parts are available at https://github.com/php/php-src/blob/PHP-7.1/ext/opcache/zend_accelerator_util_funcs.c#L561 and https://github.com/php/php-src/blob/PHP-7.1/ext/opcache/zend_accelerator_util_funcs.c#L341

The current PR should improve performances by only loading the required symfony services, and not load a very very huge class that is the container.
Loading a huge class, just to use a little part of its methods at runtime, is a waste of resources.

…tiated services (nicolas-grekas) This PR was merged into the 2.7 branch. Discussion ---------- [Bridge\ProxyManager] Dont call __destruct() on non-instantiated services | Q | A | ------------- | --- | Branch? | 2.7 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - While working on making #23678 green, I discovered that if a lazy service implements `__destruct`, then that service is not lazy anymore: it is created at destruct time. That behavior is documented at Ocramius/ProxyManager#258 (+related issues). While I may understand why this behavior is the default for ProxyManager, it does not fit our "lazy-services" use case to me. Typically, nobody wants a database connection to be created to destruct the uninitialized lazy-proxy. Blocks #23678 Commits ------- 2d79ffa [Bridge\ProxyManager] Dont call __destruct() on non-instantiated services

nicolas-grekas · 2017-08-03T15:51:22Z

I'm now targeting 3.4, see #23741

…ekas) This PR was merged into the 3.4 branch. Discussion ---------- [DI] Generate one file per service factory | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #23601 | License | MIT | Doc PR | - See #23678 for background on this proposal. Commits ------- 4037009 [DI] Generate one file per service factory

nicolas-grekas · 2017-09-23T20:45:09Z

The most significant improvement of this PR should be on the CLI, where OPcache doesn't work.
See #23601 (comment)

excursions · 2018-04-03T12:24:10Z

src/Symfony/Component/HttpKernel/Kernel.php

@@ -671,9 +671,29 @@ protected function dumpContainer(ConfigCache $cache, ContainerBuilder $container
            $dumper->setProxyDumper(new ProxyDumper(md5($cache->getPath())));
        }

-        $content = $dumper->dump(array('class' => $class, 'base_class' => $baseClass, 'file' => $cache->getPath(), 'debug' => $this->debug));
+        $content = $dumper->dump(array('class' => $class, 'base_class' => $baseClass, 'file' => $cache->getPath(), 'as_files' => true, 'debug' => $this->debug));


@nicolas-grekas What is the reason to hardcode as_files value?

After upgrading to Symfony 3.4 our tests won't run on the CI platform because they hit the open files limit.

Because there are many benefits to splitting the container into several files.
ow does this relates to fopen any limit? Service files should be closed by PHP as soon as they are consumed, isn't it?

@nicolas-grekas I meant the limit imposed by /etc/security/limits.conf (which includes all loaded files).

You maintain here that you've "updated the Kernel to set that flag in non-debug envs", but this is not the case.

Is there any way to get around this option apart from overriding Kernel:dumpContainer() (which doesn't seem a good idea)?

/etc/security/limits.conf (which includes all loaded files)

I only see nofile, which limits currently open files. Doesn't PHP close them once executed, thus the culprit is elsewhere?

get around this option

not really as this should work for everyone...

It does close them, except if the file is autoloaded, and needs to autoload another file, in such a case, the chain will remain open until last statement

We run the tests with coverage and thus with phpdbg which may be the curlpit, as you suggested...

Yes, phpdbg has the max_open_file problem , I dont really know why , I guess it loads PHP files differently from other SAPI , I should have a look at the source code for that.

You should increase the limit by using ulimit -n

@nicolas-grekas @jpaul
Thank you for this feedback.
Unfortunately ulimits are not available on Codeship.

This option has been added in `symfony/dependency-injection` v4 and the idea is to reduce the amount of files/classes loaded when the container is initialised, thus reducing memory usage and speeding up things. More info: symfony/symfony#23678

nicolas-grekas added this to the 4.0 milestone Jul 26, 2017

carsonbot added Status: Needs Review DependencyInjection Feature labels Jul 26, 2017

nicolas-grekas added Status: Needs Work and removed Status: Needs Review labels Jul 26, 2017

nicolas-grekas commented Jul 26, 2017

View reviewed changes

nicolas-grekas force-pushed the di-split branch 2 times, most recently from a714810 to 736bc22 Compare July 26, 2017 10:16

nicolas-grekas force-pushed the di-split branch from 736bc22 to c6062d6 Compare July 26, 2017 19:52

nicolas-grekas mentioned this pull request Jul 27, 2017

[DI][ProxyManager] Pass the factory code to execute to DumperInterface::getProxyFactoryCode() #23693

Merged

nicolas-grekas force-pushed the di-split branch 3 times, most recently from 528afec to e709ccf Compare July 27, 2017 13:27

nicolas-grekas force-pushed the di-split branch 3 times, most recently from e5c35a7 to 88aea90 Compare July 27, 2017 20:49

nicolas-grekas force-pushed the di-split branch 6 times, most recently from dc0fc39 to 9628fbe Compare July 29, 2017 14:12

nicolas-grekas changed the title ~~[DI] Generate one factory class per private service~~ [DI] Generate one file per service factory Jul 29, 2017

nicolas-grekas force-pushed the di-split branch from b0696a3 to 14ff9a3 Compare July 31, 2017 07:57

nicolas-grekas mentioned this pull request Jul 31, 2017

[Bridge\ProxyManager] Dont call __destruct() on non-instantiated services #23729

Merged

[Bridge\ProxyManager] Dont call __destruct() on non-instantiated serv…

e95b438

…ices

nicolas-grekas force-pushed the di-split branch 4 times, most recently from 1b81099 to e91ba87 Compare July 31, 2017 21:09

[DI] Generate one file per service factory

359b6ef

nicolas-grekas force-pushed the di-split branch from e91ba87 to 359b6ef Compare August 1, 2017 12:44

nicolas-grekas mentioned this pull request Aug 1, 2017

[DI] Generate one file per service factory #23741

Merged

nicolas-grekas closed this Aug 3, 2017

nicolas-grekas deleted the di-split branch August 3, 2017 15:51

excursions reviewed Apr 3, 2018

View reviewed changes

lcobucci mentioned this pull request May 6, 2018

Dump container in multiple files lcobucci/di-builder#14

Merged

jvasseur mentioned this pull request Aug 9, 2018

RFC: Use bundle class for container extensions #28170

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[DI] Generate one file per service factory #23678

[DI] Generate one file per service factory #23678

nicolas-grekas commented Jul 26, 2017 •

edited

Loading

nicolas-grekas Jul 26, 2017

nicolas-grekas Jul 27, 2017

nicolas-grekas Jul 26, 2017

javiereguiluz commented Jul 26, 2017

nicolas-grekas commented Jul 26, 2017

robfrawley commented Jul 26, 2017

nicolas-grekas commented Jul 27, 2017

nicolas-grekas commented Jul 31, 2017

ogizanagi commented Aug 1, 2017 •

edited

Loading

nicolas-grekas commented Aug 1, 2017 •

edited

Loading

ogizanagi commented Aug 1, 2017

nicolas-grekas commented Aug 2, 2017

jpauli commented Aug 3, 2017

nicolas-grekas commented Aug 3, 2017

nicolas-grekas commented Sep 23, 2017

excursions Apr 3, 2018

nicolas-grekas Apr 3, 2018

excursions Apr 3, 2018

nicolas-grekas Apr 3, 2018

jpauli Apr 3, 2018

excursions Apr 3, 2018

jpauli Apr 3, 2018

excursions Apr 3, 2018

[DI] Generate one file per service factory #23678

[DI] Generate one file per service factory #23678

Conversation

nicolas-grekas commented Jul 26, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

javiereguiluz commented Jul 26, 2017

nicolas-grekas commented Jul 26, 2017

robfrawley commented Jul 26, 2017

nicolas-grekas commented Jul 27, 2017

nicolas-grekas commented Jul 31, 2017

ogizanagi commented Aug 1, 2017 • edited Loading

nicolas-grekas commented Aug 1, 2017 • edited Loading

ogizanagi commented Aug 1, 2017

nicolas-grekas commented Aug 2, 2017

jpauli commented Aug 3, 2017

nicolas-grekas commented Aug 3, 2017

nicolas-grekas commented Sep 23, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nicolas-grekas commented Jul 26, 2017 •

edited

Loading

ogizanagi commented Aug 1, 2017 •

edited

Loading

nicolas-grekas commented Aug 1, 2017 •

edited

Loading