Send customizable Cache-Control headers for entries

[Leonard Richardson]

Let's imagine a resource that changes very rarely. Say, once a month. It would be nice to send a Cache-Control header that tells clients not to make requests for this resource more often than, say, once a week. If a client's request is poorly timed, they might have bad data for up to a week, but it's worth it to avoid a whole lot of requests to a resource that changes very rarely.

OK, we do have a resource that changes once a month: the service root. And we do send a Cache-Control header that tells clients not to make requests for this resource more often than once a week. This bug says: let's do the same for entry resources!

Entry resources are tricky! That's why we didn't do this already. There are some that never change, bug comments, but nobody uses launchpadlib to grab individual bug comments. The ones most users care about -- bugs, people, distributions, and releases of distributions -- change unpredictably. We don't want a client to have out-of-date bug data even for an hour.

However, recently I run some log analysis that indicates our biggest users could reap big benefits from these entries being served with Cache-Control headers whose max-age was as low as 60 seconds. Or 30 seconds. Or even 15 seconds. I'm seeing three or more requests to the same object within a couple of seconds, sometimes adding up to hundreds of requests to a given object over the course of a day.

Most of these requests return 304 response codes--they weren't necessary. These requests are dominated by HTTP latency (since the server doesn't do anything when it receives them) so the only way to optimize them is to make the client stop making them. Ideally we'd be able to prevent all those hundreds of requests, but we could divide the number of requests by about three by setting a max-age of 15 seconds for people, bugs, distributions, and releases. As always, we reduce the requests further by increasing the max-age.

Would it be okay to introduce a maximum of 60/30/15 seconds of latency for that kind of benefit?

I'm almost certain our users could greatly decrease the number of requests they make by rewriting their code. And I believe we could do some work in lazr.restfulclient to make some of the code written now make fewer HTTP requests. But given my discovery that even very low values for max-age can have big performance effects, I thought I'd resurrect the max-age idea.

[Gary Poster (gary)]

I'm a bit nervous about forcing this to happen. I'm inclined to go down the road of explicit start-cache-stop-cache gestures as we've discussed before. As you pointed out on IRC, the obvious downside is that this requires someone to change code for us to see the benefit. However, if we have very few high-traffic users, encouraging these changes might be easy.