-
-
Notifications
You must be signed in to change notification settings - Fork 865
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
VarnishPurger cannot handle alot of entities #1856
Comments
Would #1776 help? 😄 |
Any news on this issue? |
As a workaround, you can do that: api-platform/demo@0bc6849#diff-628212751f227bfce20484adbd0d4191R1 Maybe can we enable the Varnish subsystem only for the |
I'd again argue that there's a need for the developer to verify that the caching (especially the invalidation) by reverse proxy works as expected in the |
And it's a bug we need to fix anyway. |
The only way to "fix" it is to skip the listener in those specific batch cases. It's up the developper to purge Varnish using another way (probably a full purge) in those cases. But dev commands such as Doctrine Migrations ones must work. |
A more efficient cache invalidation method should help. But yes, of course we could never guarantee that there will not be a timeout if a certain higher limit is still hit. That will be up to the developer to improvise. My point of disagreement is mainly on disabling it out of the box in the |
We may at least disable it in CLI + dev to allow such commands to work. |
Proposal: if in debug mode + cli : log a warning but disable it. |
Perhaps also relevant: #1286 (comment) |
I'm also having this issue trying to import data with Doctrine from a command (Which I need to do in production too). |
I also have the issue in a prod environment when invalidating an object with a lot of relations, so it's definitely not only related to dev commands |
I'm having this issue too when I change my profile picture to my API hosted on GKE. Is there a workaround ? |
Hello,
But I do not know how to extend that class as it is declared final, for now I have modified directly the file on vendor/api-platform/core/src/HttpCache/VarnishPurger.php |
@applizem above worked for executing fixtures but admin part stopped responding for me :/ |
I'd really like to encourage doing smaller / more requests, if you could afford to. More granular requests could also help with cache hits, as you'd reduce specialized requests. |
For me this is happening when I trigger fixtures via |
To prevent the problem when loading fixtures, you can enable the cache invalidation mechanism only for the prod environment. It's what we've done in the demo: https://github.com/api-platform/demo/blob/master/api/config/packages/prod/api_platform.yaml#L7-L11 |
I don't agree. We are talking about Symfony environments here. |
@dunglas Should we ship that as the default then?
Going by that logic, perhaps we shouldn't ship the varnish ("cache-proxy") container in our Docker Compose setup? |
Yes I think so.
You mean that we need a |
I have already worked on that, if you'd accept it. 😉 I could open a PR. |
Let's do that then |
Includes now defunct API Platform Varnish configuration. From https://github.com/api-platform/api-platform/blob/v2.5.7/api/docker/varnish/conf/default.vcl Please note that is a BAN based purge (which is kinda meh ?) Please see also FriendsOfSymfony/FOSHttpCache#495 api-platform/core#1856 api-platform/api-platform#1947
Includes now defunct API Platform Varnish configuration. From https://github.com/api-platform/api-platform/blob/v2.5.7/api/docker/varnish/conf/default.vcl Please note that is a BAN based purge (which is kinda meh ?) Please see also FriendsOfSymfony/FOSHttpCache#495 api-platform/core#1856 api-platform/api-platform#1947
Includes now defunct API Platform Varnish configuration. From https://github.com/api-platform/api-platform/blob/v2.5.7/api/docker/varnish/conf/default.vcl Please note that is a BAN based purge (which is kinda meh ?) Please see also FriendsOfSymfony/FOSHttpCache#495 api-platform/core#1856 api-platform/api-platform#1947
Based on this commit: Simperfit/api-perf@4201cc2#diff-c828d4117439a2216f86c406d522c79c
To reproduce it
Results in:
The text was updated successfully, but these errors were encountered: