[HttpCache] Do not call terminate() on cache hit #46763
Conversation
90348c9 to
c7b7593
Compare
|
Failing tests unrelated, imho. |
|
Mentioning some users of |
|
I think it makes (a lot of) sense for eZ=>Ibexa as well, but as I'm not there anymore I'll ping @bdunogier who might know who is involved in this now |
|
That seems reasonable. |
There was a problem hiding this comment.
this seems reasonable to me. the other kernel events are also not triggered on a cache hit (as the cache kernel does not forward the request to the wrapped kernel). having only the terminate event seems odd. and indeed, when a separate caching proxy is used, no terminate is triggered.
the code was added over a decade ago: 7efe4bc
i can see the fear of breaking some existing systems. i think most delayed tasks should not be needed after a cache hit, but if some sort of reporting is done in the framework it might care about cache hits too.
another option could be to use a flag whether to forward the termination event for cache hits that defaults to true for now, and maybe do a deprecation warning if it is not set to false, to make people aware that the behaviour will change.
without a flag, the behaviour can be changed by extending the HttpCache class and overwriting the terminate method to unconditionally forward the event.
|
To me, this is definitely a bug so I don't see why this would not need to be fixed in 4.4. Not sure if I should deprecate this as I did now. And if so, how the heck did we expect deprecations in 4.4? With the annotation still - so I would need to have two test methods and cannot use |
There was a problem hiding this comment.
regarding bug vs change, i think we are here in really a gray area.
there is nothing technically wrong with calling terminate. no security risk, no exceptions happening. you can't be sure that nobody would want the event to happen, so i don't think its correct to consider it a bug.
it is a significant waste of server resources even if it should not affect response times directly. the option seems justified to me, and given how unlikely it is to need the event, i think it makes sense to change the default in the next major version. (e.g. logging of requests should happen at webserver level, not in PHP)
given how long it has been like this, i would vote for stability in this case and only change the default in the next major.
|
I agree, that's why the default remains untouched now. However, I think we should be given the ability to fix it easily in all actively supported versions without having to override |
|
Forgot to mention that I think this is indeed a good idea to have that in 6.2. |
|
With the option there is no BC break. It just offers the users the ability to adjust their setups in 4.4 already. |
There was a problem hiding this comment.
With the option there is no BC break. It just offers the users the ability to adjust their setups in 4.4 already. I'm unsure what I need to do now :) If you want this in 6.2 only, would you want me to still keep the option when I rebase or not? :)
We really appreciate the investigations. The proposed solution is good for the next minor version (6.2). @fabpot listed the reasons it cannot be merged in an old branch:
- it is not a security issue, not a functional bug
- it is a new feature (performance optimization are feature)
- it adds a new option
- it adds a depreciation message (which is good for changing the default behavior in 7.0)
fa6aeb5 to
c730730
Compare
c730730 to
662eb17
Compare
|
My question was just if you want to still keep the option now that we've decided it should be 6.2 but I guess we should do that. PR is updated. Failing tests seem unrelated, the current 6.2 branch does not pass apparently :) |
|
Thank you @Toflar. |
…e_on_cache_hit HttpCache option (wouterj) This PR was merged into the 6.2 branch. Discussion ---------- [FrameworkBundle] Add semantic config for new terminate_on_cache_hit HttpCache option | Q | A | ------------- | --- | Branch? | 6.2 | Bug fix? | no | New feature? | yes | Deprecations? | no | Tickets | - | License | MIT | Doc PR | symfony/symfony-docs#16999 Adds the semantic configuration for the option introduced in Symfony 6.2 by #46763 Commits ------- bb387e9 [FrameworkBundle] Add semantic config for new terminate_on_cache_hit HttpCache option
Currently,
HttpCachealways calls thekernel.terminateevents, even if the response is coming from cache.Why is this a problem?
kernel.terminateevents are used to do things after the response has been sent to the visitor. At least that happens if you have support forfastcgi_finish_request().For Contao for example, we use this to dispatch a message to update the search index but you can imagine a lot of stuff being done there, like sending e-mails etc. According to the docs, it says "perform some heavy action".
This means that currently, the system is basically always booted even when the response is coming from
HttpCachebecause dispatching theTerminateEventcauses the container to be booted etc. which makes the system slower than it needs to be.We don't need to update the search index when the response is coming from the cache because it already is up to date. And there are no e-mails or other "heavy actions" to perform because by definition, nothing could've happened as the system was not booted (or should not have been).
Also, imagine if you used a "real" reverse proxy like Varnish. There's no call to the back end either when there's a cache hit so it's actually an inconsistency. You cannot "perform some heavy action" there either. If you wanted to, it would have to be implemented in the proxy itself. So Varnish would need to trigger that heavy action. HttpCache should behave just the same.
You could e.g. use the
EventDispatchingHttpCachefrom https://github.com/FriendsOfSymfony/FOSHttpCache, if you need something like that.