Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[FrameworkBundle] Default to Apcu+Filesystem cache chain #18715

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 13, 2016

Conversation

nicolas-grekas
Copy link
Member

Q A
Branch? 3.1
Bug fix? yes (perf)
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets -
License MIT
Doc PR -

In #16838, @dunglas benched that the filesystem cache is not the fastest one (not a surprise).
Yet, it is the default for now. I propose to replace this default by a dynamically created one that uses APCu when available (of course, we cannot do the check at container-build time), chained with the filesystem.

The benefit is double: APCu is automatically used when available without any configuration, and cache warming up is seeded by the filesystem cache so that the apcu cache can benefit from it.

@dunglas
Copy link
Member

dunglas commented May 5, 2016

👍

@nicolas-grekas
Copy link
Member Author

Includes #18716 until it's merged

@nicolas-grekas nicolas-grekas force-pushed the cache-default branch 5 times, most recently from 005e8d4 to e300496 Compare May 6, 2016 09:28
$apcu->setLogger($logger);
}

return new ChainAdapter(array($apcu, $fs));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if creation of the default adapter belongs here. Imo we should deal with this in the FrameworkBundle extension.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

factory moved to FrameworkBundle (I don't like creating/loading yet another utility class just for the factory)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

factory back on the component following comment from @fabpot

@@ -1037,6 +1037,7 @@ private function registerPropertyInfoConfiguration(array $config, ContainerBuild

private function registerCacheConfiguration(array $config, ContainerBuilder $container, XmlFileLoader $loader)
{
$container->setParameter('kernel.cache_nonce', substr(base64_encode(md5(uniqid(mt_rand(), true), true)), 0, 4));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using mt_rand means that each rebuilding of the container will change this value. And each server behind the load balancer may have a different value if they build their container themselves (rather than building it once before deploying), making it unusable for configuring a shared cache. Is it the intended behavior ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this is the indented behavior: this nonce is only for local caches (apcu is the only use case in fact today).

@nicolas-grekas nicolas-grekas force-pushed the cache-default branch 4 times, most recently from 7ea44b2 to 3a3e789 Compare May 8, 2016 22:57
@nicolas-grekas
Copy link
Member Author

ping @symfony/deciders votes pending for 3.1-beta which should/may be released tomorrow

@@ -22,6 +22,17 @@
<tag name="cache.pool" />
</service>

<service id="cache.adapter.system" class="Symfony\Component\Cache\Adapter\ChainAdapter" abstract="true">
<factory class="Symfony\Bundle\FrameworkBundle\FrameworkBundle" method="createSystemCache" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would move this factory to the component instead as the code in the method is not tied to the full-stack framework. I'd like to be able to reuse this strategy into Silex for instance.

@@ -22,6 +22,17 @@
<tag name="cache.pool" />
</service>

<service id="cache.adapter.system" class="Symfony\Component\Cache\Adapter\ChainAdapter" abstract="true">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about using the interface as the class here as the service can also just be a FilesystemAdapter?

@xabbuh
Copy link
Member

xabbuh commented May 12, 2016

👍

@nicolas-grekas nicolas-grekas force-pushed the cache-default branch 2 times, most recently from 5e3dc85 to ae1d7dc Compare May 13, 2016 17:33
@fabpot
Copy link
Member

fabpot commented May 13, 2016

Thank you @nicolas-grekas.

@fabpot fabpot merged commit b9b57f9 into symfony:master May 13, 2016
fabpot added a commit that referenced this pull request May 13, 2016
…in (nicolas-grekas)

This PR was merged into the 3.1-dev branch.

Discussion
----------

[FrameworkBundle] Default to Apcu+Filesystem cache chain

| Q             | A
| ------------- | ---
| Branch?       | 3.1
| Bug fix?      | yes (perf)
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

In #16838, @dunglas benched that the filesystem cache is not the fastest one (not a surprise).
Yet, it is the default for now. I propose to replace this default by a dynamically created one that uses APCu when available (of course, we cannot do the check at container-build time), chained with the filesystem.

The benefit is double: APCu is automatically used when available without any configuration, and cache warming up is seeded by the filesystem cache so that the apcu cache can benefit from it.

Commits
-------

b9b57f9 [FrameworkBundle] Default to Apcu+Filesystem cache chain
@fabpot fabpot mentioned this pull request May 13, 2016
@nicolas-grekas nicolas-grekas deleted the cache-default branch May 14, 2016 12:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants