[MGNLADVCACHE-61] On "Serving from old cache": Serve also the first visitor from old cache, and let the back end trigger the re-rendering for re-caching. Created: 16/Sep/15 Updated: 27/Nov/17 Resolved: 05/Dec/16 |
|
| Status: | Closed |
| Project: | Advanced Cache |
| Component/s: | core |
| Affects Version/s: | 1.7.1 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Neutral |
| Reporter: | Christian Ringele | Assignee: | Jan Haderka |
| Resolution: | Won't Fix | Votes: | 2 |
| Labels: | support | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Template: |
|
||||
| Acceptance criteria: |
Empty
|
||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||
| Date of First Response: | |||||
| Visible to: |
Vivian Steller, zzzzJens Kolb (Lemonize) (Inactive)
|
||||
| Description |
|
The idea comes form a support case: SUPPORT-5122 When using the strategy "Serving from old cache": Now an idea, inspired by the "'Eager re-caching" strategy: So everybody gets all the time fast responses, instead of having a first visitor waiting. |
| Comments |
| Comment by Jan Haderka [ 25/Sep/15 ] |
|
This is exactly why the eager re-caching strategy exists so that none have to wait. |
| Comment by Michael Büchele [ 25/Sep/15 ] |
|
@Jan |
| Comment by Jan Haderka [ 25/Sep/15 ] |
|
You should be able to configure number of items for which this happens by setting eagerRecache property on the flush policy. You should also really do this only for often accessed pages rather than blindly for everything as you might end up using big amount of extra resources (memory, cpu) on the server and at some point benefits of recaching will be totally offset by the extra load. Just for clarification, the technical problems behind this particular request
That doesn't mean that in some specific case, with just few and really slow pages on the server it can't work, only that such solution is not applicable to most/all scenarios utilised by clients. If you really want to force it you are free to extend existing ServeUntilRecachedPolicy and combine it with EagerRecache but be aware of the drawbacks mentioned above. |
| Comment by Michael Büchele [ 25/Sep/15 ] |
|
So - to sum it up - there is currently no proper solution to always serve cached pages to visitors? |
| Comment by Christian Ringele [ 09/Feb/16 ] |
|
( I re-opened) I'm not happy with the answer "This is exactly why the eager re-caching strategy exists so that none have to wait.". Why letting the first request going though the new cache, instead of doing it by the backed? And the last input: Cheers |
| Comment by Jan Haderka [ 09/Feb/16 ] |
Currently we provide the two strategies. What you are asking for is the third one. Of course it can be developed, however even with that we do not cover all possible imaginable strategies.
The current demand for described strategy is too low to develop it in comparison to other requested new features.
Technically, we don't support nesting of different strategies. You have to choose one that you want to use. Of course you are free to write custom strategy that combines both.
If none of the out-of-the-box provided strategies fits your needs, you are free to look at the existing strategies and develop and deploy custom strategy that does exactly what desired. |
| Comment by Michael Büchele [ 10/Feb/16 ] |
|
Hi guys, 1) 2)
We have been trying to find a solution to our cache problem for about 5 months now, and are really disappointed that no proper solution seems to be available, and not even the demand is "accepted". Feels like we're left alone here and should figure out something ourselves 3)
We are not desiring anything fancy here - just that no "human visitor" should have to wait for a page to be built - that should always be done by the backend. Thanks a lot and hopefully this ticket will not be closed unsolved once again... |
| Comment by Christian Ringele [ 31/May/16 ] |
|
I'm still not sure if we speak about the same, what I mean is: What I dislike: Please answer the question(s) above directly. ---------------------------------------
As explained above I don't think about a combination, nor a third strategy.
If you think I ask for a third strategy yes, but I don't. You really want to tell me that customers would no be demanding option 2 if they knew? |
| Comment by Michael Büchele [ 31/May/16 ] |
|
|
| Comment by Jan Haderka [ 05/Dec/16 ] |
|
Yes, all the reasons why yet another custom policy is required for such corner cases are valid. And there's even more of other corner cases that you have not listed that would require yet more custom policies. For those reasons, policies are fully customizable and every user can implement the one that solves their corner case, while limited amount of base policies covers only most common use cases. |