Current caching strategy is suboptimal for the phone
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| unity-scope-click (Ubuntu) |
Triaged
|
Medium
|
Unassigned | ||
Bug Description
While investigating phone http timings & http client side caching, Pawel noticed that https:/
Part of the problem here is the embedding of resources: the API Root, for example, embeds a full tree of Departments, and several Highlights that in turn embed the highlighted Packages. A change to any Package that is part of a Highlight invalidates the cache for the Package, the Department it is categorised under, the Highlight it is featured in, and the API Root. But the Package update is just a single request, so we would then need some fairly complex logic to cascade down to the other affected resources to invalidate the cache.
We have configurable cache lifetimes for Package (10m), Search (61s), Highlight (61s), Department (1h) and Recommendation (1h). Channel, Framework and the API root all use the default value (61s), so while we can change the configured default, it'll affect all those endpoints. This is an oversight that needs to be fixed, but probably doesn't help here.
Where we need to be careful here is that the API Root is the "front door" of the Store - as soon as someone hits the Store scope, they'll be presented with Highlights like "App of the Day" prominently displayed. These are a call to action, designed to entice the user to install the app: the user clicks on the app in the highlight and... if the developer has removed the package between the resource being cached and the cache expiring, the user gets a blank page instead of the Package details and an Install button, which is a poor experience.
Maybe we could do something with conditional GETs (difficult, because determining whether the view has changed involves all the processing overhead of creating the view again, so we eliminate any speed improvements), or maybe we could just tentatively bump up the cache expiry time until we find a good compromise.
| Changed in click-package-index: | |
| status: | New → Triaged |
| importance: | Undecided → High |
| assignee: | nobody → James Tait (jamestait) |
| James Tait (jamestait) wrote | #1 |
| Changed in click-package-index: | |
| status: | Triaged → Fix Committed |
| Changed in click-package-index: | |
| status: | Fix Committed → Fix Released |
| assignee: | James Tait (jamestait) → nobody |
| Changed in unity-scope-click (Ubuntu): | |
| status: | New → Triaged |
| importance: | Undecided → Medium |
Having looked a bit further into this, it seems the only case we're likely to run into problems is where an embedded package is removed from the store entirely during the client cache validity period. In this case, the client will present its cached view, and once the user selects the removed package in the highlight, the client will request the details page and the index will return a 404. Once the cache expires and the device re-requests the top-level resource, the response will be recomputed and will not include the removed package.
In light of this, we will reconfigure the default cache expiry to be 3,600 seconds (1 hour) and suggest that the click scope be slightly smarter, invalidating its local cache when encountering 404 responses for embedded resources.