Love the image resizing product so far and its integration with workers!
One thing we’re unsure about as we’re moving towards deploying a feature based on these:
It costs $9 to resize/process 50k images. Will an image that has already been resized and resides in cache in at least one of CF’s datacenters be fetched from origin and thus resized again when a user tries to access the same image from a geographically different area, or not?
I could imagine CF just fetching it from a datacenter it knows it’s already cached at, because that would potentially be more efficient from a CPU usage viewpoint. But on the other hand that might require CF to keep track of what’s already cached where and maybe that’d be too hard a problem to require solving for potentially relatively little benefit…
While researching further, I’ve learned that Argo Tiered Caching is now free to enable and should reduce the number of origin requests and thus also requests that need to do image processing.
So the answer does seem to be that I do have to expect multiple requests per image, even if already cached in at least one geographic area. Tiered Caching should improve the cache hit rate at the very least for geographically close user requests, but one would have to try it out in production to understand the specific cache hit rates that are to be expected.
EDIT:
And now that Cache Reserve is available to everyone, that should also be a no-brainer to enable to further reduce the number of resizings that need to be done and paid for.
Just be aware that if you want to use that, then ensure your origin does not send, or that you do explicitly delete, the ‘Vary’ header on the image responses, before you put them into the cache.