-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[FrameworkBundle] Dont store cache misses on warmup #40645
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
Conversation
512e889
to
3cec54f
Compare
src/Symfony/Bundle/FrameworkBundle/Tests/CacheWarmer/AnnotationsCacheWarmerTest.php
Show resolved
Hide resolved
@carsonbot could you find me a reviewer please? |
I'm sorry. I could not find any suitable reviewer. |
Oh. I guess it was too long ago @dmaicher wrote this class =) David, do you mind having a look at this PR? |
Thanks for the quick fix :) If I understand correctly though, this means using lambdas like that will prevent caching of the resolved config and it'll reload on every request needing it. I guess it's thus worth avoiding lambda callbacks.. |
Yes, that is correct. |
I updated the docs with this observation: symfony/symfony-docs#15172 |
Storing misses is an important part of the performance provided by system caches. |
Yes, but these "misses" are interpreted as "hits". A "hit" with null is not the same as a miss. There should never be "null" stored in this cache. I have two alternative solutions. The first would be to find a way to serialize a |
The test case passes even without the change if I didn't mess up :)
For system caches, aka the ones sourced by the code itself, we can do this - cache misses.
Why a closure ends up in the cache? That's the main question I have here indeed. An annotation should not lead to a closure because then of course it cannot be cached - while the source is a plain descriptive annotation. The second solution would be a major regression actually. Can you try this patch instead? It tries to not store misses for failures-to-save().
|
You did mess up =)
Because we cache an object of
I think that would work. But the end result would be the same. We would reread the annotations at runtime. |
I confirm :P
I just read the doc PR, nice one.
True, but we would still store misses, and this is important for the other system caches.
OK great, then I suppose other system caches need this. Annotations are not the only system caches, but the current patch changes the behavior for all of them. |
… (Nyholm) This PR was squashed before being merged into the 4.4 branch. Discussion ---------- [Validator] Add warning about closure not being cachable Follow up from symfony/symfony#40645 The annotation cache will not work with `Closure`. If I understand correctly, it is not possible to have external dependencies in your custom validator AND get your annotation cached. You have to chose one or the other. Commits ------- ebddb78 [Validator] Add warning about closure not being cachable
$values = array_filter($values, function ($val) { | ||
return $val !== null; | ||
}); | ||
|
||
// make sure we don't cache null values | ||
parent::warmUpPhpArrayAdapter($phpArrayAdapter, array_filter($values)); | ||
parent::warmUpPhpArrayAdapter($phpArrayAdapter, $values); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
array_filter($values)
will also remove everything that is empty
.
There is no test for this code and I am not sure why null
should be removed. I can only assume it is because of the callback =)
I was wrong patching
This is not reliable. If a user does something like this, the bug will occur again. $i = $cache->getItem('foo');
$i->set('data');
$cache->save($i); // Save failed for some reason.
// ...
$cache->getItem('foo'); |
src/Symfony/Bundle/FrameworkBundle/CacheWarmer/AnnotationsCacheWarmer.php
Outdated
Show resolved
Hide resolved
src/Symfony/Bundle/FrameworkBundle/CacheWarmer/AnnotationsCacheWarmer.php
Show resolved
Hide resolved
The PR is updated |
…pter (nicolas-grekas) This PR was merged into the 4.4 branch. Discussion ---------- [Cache] skip storing failure-to-save as misses in ArrayAdapter | Q | A | ------------- | --- | Branch? | 4.4 | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | Fix #38694 | License | MIT | Doc PR | - In addition to #40645 Commits ------- ba66987 [Cache] skip storing failure-to-save as misses in ArrayAdapter
d249500
to
27a22b3
Compare
Thank you @Nyholm. |
When we are warming the annotation cache, we are reading all annotation into an
ArrayAdapter
. When we are done we move the values to aPhpArrayAdapter
to store them in a file.@Seldaek found out that when you are using a custom constraint with a
Symfony\Component\Validator\Constraints\Callback
, there is a strange error like:That is because the
Closure
in theSymfony\Component\Validator\Constraints\Callback
cannot be serialised and saved to cache. But since theArrayAdapter
is also storing misses as null, the null values are understood as real values.When all values are moved to the
PhpArrayAdapter
and we ask the cache for a value (via Doctrine'sCacheProvider
), it will returnnull
as a value instead offalse
as a cache miss. Andnull
is not something one could "yield from".