Current caching strategy is suboptimal for the phone

Bug #1574766 reported by James Tait on 2016-04-25
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Click Package Index
High
Unassigned
unity-scope-click (Ubuntu)
Medium
Unassigned

Bug Description

While investigating phone http timings & http client side caching, Pawel noticed that https://search.apps.ubuntu.com/api/v1 endpoint still has an expiration of 60 seconds. We have previously discussed relaxing it and it was suggested that 1h would be reasonable.

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.

James Tait (jamestait) on 2016-04-27
Changed in click-package-index:
status: New → Triaged
importance: Undecided → High
assignee: nobody → James Tait (jamestait)
James Tait (jamestait) wrote :

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.

James Tait (jamestait) on 2016-04-27
Changed in click-package-index:
status: Triaged → Fix Committed
James Tait (jamestait) on 2016-04-27
Changed in click-package-index:
status: Fix Committed → Fix Released
assignee: James Tait (jamestait) → nobody
dobey (dobey) on 2016-08-15
Changed in unity-scope-click (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers