WIP: Pluggable caching backends #647

bzikarsky · 2019-03-01T08:30:48Z

Overview

This PR relates to #589 and refactors SourceCache into pluggable caching-backends while keeping backwards compatibility.

Current state

Implemented new caching classes
Integrated new caching classes into ContainerBuilder
Added unit-tests for the new classes

Establish interface Cache\Cache which represents any definition-cache
Move logic from SourceCache to both Cache\AbstractCache and
Cache\ApcuCache
Deprecate SourceCache in favour of Cache\ApcuCache but still
keep its functionality by extending the former. This is to keep
backwards compatibility
Create a new simple cache-backend ArrayCache which just caches
lookups in memory

Integrate new Cache backend into ContainerBuilder

Instead of tracking the caching status with a boolean, this commit changes
$sourceCache to a nullable string. This allows to define different cache-
backends.

::enableDefinitionCache(..) not takes an optional parameter - optional to
keep backwards compatibility - with the class-name of the definition cache to
use. By default the ApcuCache is used which is identical to the deprecated,
original SourceCache

Tests

TODO 😄

Future work

This functionality can be used to provide adapters to more general caching-backends, such as PSR-6 or PSR-16 compatible libraries.
In a major release SourceCache can be removed.

mnapoli · 2019-03-01T10:52:31Z

Hi, thank you for the effort you put into that!

Unfortunately I'm still not sure I understand the need behind that.

The other thing is that this adds a lot of complexity and new code to maintain, and using an abstraction or PSR-6/16 adds overhead as well. I did some testing back then and using Doctrine Cache (which is fairly optimized) did add some overhead compared to a custom and simple cache implementation around APCu directly.

src/Definition/Source/SourceCache.php

SvenRtbg · 2019-03-01T11:05:08Z

src/Definition/Source/DefinitionSource.php

    /**
     * Returns the DI definition for the entry name.
     *
+     * @param string $name The name of the definition to get


Not a big fan of adding obvious annotations. The type is already enforced, and the explanation for a method "getDefinition" with the parameter "name" is also pretty obvious: You get the definition for the name.

I think if there is a docblock, it should be complete, shouldn't it? I'm all for dropping the comment after $name though.

My personal opinion: Docblocks should be as short as possible, and should not contain redundant information. Comments will start to contain wrong information in the long run, the less info they contain, the better.

Now, PHP-DI is a little bit inconsistent in this regard. If you look over some code, you'll find methods like this

PHP-DI/src/ContainerBuilder.php

Lines 220 to 226 in f16f27b

* Enable or disable the use of autowiring to guess injections.

*

* Enabled by default.

*

* @return $this

*/

public function useAutowiring(bool $bool) : self

without @param for the parameter and the opposite like this

PHP-DI/src/ContainerBuilder.php

Lines 272 to 278 in f16f27b

*

* @param bool $writeToFile If true, write the proxies to disk to improve performances

* @param string|null $proxyDirectory Directory where to write the proxies

* @throws InvalidArgumentException when writeToFile is set to true and the proxy directory is null

* @return $this

*/

public function writeProxiesToFile(bool $writeToFile, string $proxyDirectory = null) : self

with every parameter annotated and commented.

I cannot define the code style for this project, @mnapoli is the project lead.

SvenRtbg · 2019-03-01T11:08:27Z

src/ContainerBuilder.php

+     * @var string|null
     */
-    private $sourceCache = false;
+    private $sourceCache;


I'd probably use another name for this property for defining the class name instead of recycling a property that already has a meaning, especially if it's type would change.

Renaming the property is a non-issue. What would you prefer?

cacheClass

bzikarsky · 2019-03-01T12:10:52Z

The need for this is simple: If you run PHP in any long-running-process configuration (php-pm, amp, etc.) it's fully sufficient to simply cache in-memory. APCu is an overhead for us, we don't even run it in production. I also think that the introduced overhead of 2 method calls is negligable. In the end it's still only 1 object which does the same as SourceCache - only that apc_fetch and apc_store are moved behind those 2 new methods.

Essentially it comes down to this: We have currently a copy of SourceCache and ContainerBuilder in our source-tree solely for the purpose to cache into arrays. It'd be great to be able to drop those.

If you give your 👍 I will addthe missing tests for the new classes.

- Establish interface `Cache\Cache` which represents any definition-cache - Move logic from `SourceCache` to both `Cache\AbstractCache` and `Cache\ApcuCache` - Deprecate `SourceCache` in favour of `Cache\ApcuCache` but still keep its functionality by extending the former. This is to keep backwards compatibility - Create a new simple cache-backend `ArrayCache` which just caches lookups in memory

Instead of tracking the caching status with a boolean, this commit changes `$sourceCache` to a nullable string. This allows to define different cache- backends. `::enableDefinitionCache(..)` not takes an optional parameter - optional to keep backwards compatibility - with the class-name of the definition cache to use. By default the `ApcuCache` is used which is identical to the deprecated, original `SourceCache`

bzikarsky · 2019-03-29T09:59:17Z

@mnapoli Please consider merging something along these lines. The copied and modified version of ContainerBuilder we need to maintain in our source-tree broke prod builds after a composer upgrade again.

I'm more than happy to implement the missing tests/refactorings if you greenlight this implementation.

mnapoli · 2019-04-21T14:21:32Z

@bzikarsky sorry for the delay.

The use case makes sense (not using APCu yet caching definitions in memory).

I've been thinking about this and I wonder if it wouldn't make sense to always have the in-memory cache, even when using APCu. Indeed if a process gets the same definition twice it doesn't make sense to fetch it twice from APCu. That wouldn't mean a noticeable performance improvement but I think it might be a simpler architecture (no pluggable cache backend).

What do you think?

bzikarsky · 2019-04-23T11:24:25Z

I agree on having an in-memory cache "by default".

What I don't understand yet is why you insist to not move the "concern to cache" into a separate interface. From an architecture point-of-view smaller classes with a smaller footprint make sense in my opinion (and are also easier to test).

Going with the proposed way would open the code up to all different kind of caching use-cases and with Memory(APCu()) only being one/the default.

mnapoli · 2019-04-23T11:30:54Z

Well I was thinking of a simple key-value map of definitions that were already resolved but it seems I forgot that this exists already:

PHP-DI/src/Container.php

Lines 151 to 154 in 2c7a3a6

    
           // Local cache that avoids fetching the same definition twice 
        
           if (!array_key_exists($name, $this->fetchedDefinitions)) { 
        
               $this->fetchedDefinitions[$name] = $this->definitionSource->getDefinition($name); 
        
           }

Does that cover your use case?

bzikarsky · 2020-03-17T13:18:20Z

So... I know this is a very old PR, but priorities moved, but here we are again.

I checked your proposal, but the issue is:

While Container::getDefinition uses the $this->fetchedDefinitions cache. Container::injectOn does not. We introduced hack which led to this PR, because we have a lot of injectOn callsites for legacy reasons.

I am not sure: Maybe it's just possible to make injectOn use fetchedDefinitions (or getDefinition), but I assume there is a reason that injectOn neither stores nor reads from this "cache".

I'd like to have your input:

Do you think injectOn could be modified in such a way this PR is not neccessary anymore?
If this is not the case, would you merge this PR if I rebase it on the current master?

mnapoli · 2020-03-19T13:42:48Z

I had a look, I think the fetchedDefinitions cache was omitted from injectOn() by mistake. I can't recall any reason not to use it there. (the tests should also validate that nothing break if you try to use it)

I think 1. is the simplest solution. If you manage to implement it that would be best!

bzikarsky · 2020-03-20T11:51:09Z

Closed in favour of #709

bzikarsky force-pushed the pluggable-caching-backends branch 3 times, most recently from e6cb96d to 2cbcda2 Compare March 1, 2019 08:40

SvenRtbg reviewed Mar 1, 2019

View reviewed changes

src/Definition/Source/SourceCache.php Show resolved Hide resolved

SvenRtbg reviewed Mar 1, 2019

View reviewed changes

Benjamin Zikarsky added 3 commits March 29, 2019 10:55

Add missing phpdoc @param for DefinitionSource::getDefinition(..)

147304f

bzikarsky force-pushed the pluggable-caching-backends branch from 2cbcda2 to ae5adc6 Compare March 29, 2019 09:56

mnapoli added the enhancement label Apr 21, 2019

bzikarsky mentioned this pull request Mar 20, 2020

Make injectOn use the definition cache #709

Merged

bzikarsky closed this Mar 20, 2020

	* Enable or disable the use of autowiring to guess injections.
	*
	* Enabled by default.
	*
	* @return $this
	*/
	public function useAutowiring(bool $bool) : self

	*
	* @param bool $writeToFile If true, write the proxies to disk to improve performances
	* @param string\|null $proxyDirectory Directory where to write the proxies
	* @throws InvalidArgumentException when writeToFile is set to true and the proxy directory is null
	* @return $this
	*/
	public function writeProxiesToFile(bool $writeToFile, string $proxyDirectory = null) : self

Uh oh!

WIP: Pluggable caching backends #647

WIP: Pluggable caching backends #647

Uh oh!

Conversation

bzikarsky commented Mar 1, 2019

Overview

Current state

Contents

Create an explicit, new class hierarchy for definition caching

Integrate new Cache backend into ContainerBuilder

Tests

Future work

Uh oh!

mnapoli commented Mar 1, 2019

Uh oh!

Uh oh!

SvenRtbg Mar 1, 2019

Choose a reason for hiding this comment

Uh oh!

bzikarsky Mar 1, 2019

Choose a reason for hiding this comment

Uh oh!

SvenRtbg Mar 1, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SvenRtbg Mar 1, 2019

Choose a reason for hiding this comment

Uh oh!

bzikarsky Mar 1, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SvenRtbg Mar 1, 2019

Choose a reason for hiding this comment

Uh oh!

bzikarsky commented Mar 1, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bzikarsky commented Mar 29, 2019

Uh oh!

mnapoli commented Apr 21, 2019

Uh oh!

bzikarsky commented Apr 23, 2019

Uh oh!

mnapoli commented Apr 23, 2019

Uh oh!

bzikarsky commented Mar 17, 2020

Uh oh!

mnapoli commented Mar 19, 2020

Uh oh!

bzikarsky commented Mar 20, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

SvenRtbg Mar 1, 2019 •

edited

Loading

bzikarsky Mar 1, 2019 •

edited

Loading

bzikarsky commented Mar 1, 2019 •

edited

Loading