If you know the exact url of the api request, you can purge it on specific events (e.g. edits to a file page). But you need to know the precise url. The class that sends the actual purge is named SquidUpdate I think (writing on a phone. Didnt check name. Its something like that.)
The varnish cache (we dont use squid anymore, but the various methods still have squid in their names) would work across all users if the api module declares the correct caching mode.
--bawolff On Apr 9, 2014 2:12 PM, "Gilles Dubuc" gilles@wikimedia.org wrote:
Thanks for the pointers, Brian. I imagine this affects the HTTP caching
headers and can't be too aggressive in terms of duration, otherwise if someone updates the metadata for a file, it won't be reflected in media viewer until the max age is reached, right?
I was hoping for a silver bullet that would allow us to not only cache
API responses, but also invalidate that cache when someone updates a file's information, but maybe it's not possible with our architecture. The main thing I want to check with Ops is whether squid is affected by the HTTP caching headers for API calls, to make sure that the caching benefit is effective across users, not just for someone who would re-request the same image across pageloads.
On Wed, Apr 9, 2014 at 5:27 PM, Brian Wolff bawolff@gmail.com wrote:
On Apr 9, 2014 12:16 PM, "Gilles Dubuc" gilles@wikimedia.org wrote:
Another secondary thing we can improve (and which we've mentioned in
passing during previous meetings) is to cache the results of our API requests across users, presumably at the squid level. I've emailed Ops to see what can be done in that area.
Api has support for doing this already. See smaxage url parameter and
getCacheMode method.
--bawolff
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia