We were recently contacted by Cloudflare and told we were on the wrong package for the amount of bandwidth we were using (and the type of content we were caching, mainly images from the API assets) and that we should move to the enterprise plan for $2000/mo.
Of course, this is more than a couple of years of donations so wasn’t remotely feasible, which prompted me to set up a varnish server to handle the asset requests.
This was deployed nearly 2 weeks ago and has mostly been working perfectly, however there were a couple of teething problems and some continuing niggles.
In particular there seems to be a lot of people appending the assets URL returned with /preview in order to generate a small image, this is not the correct way to get a preview image, and hasn’t been for at least a year or two, the correct way is to replace http://assets.fanart.tv/fanart/ with http://assets.fanart.tv/preview/ (you should actually just replace the fanart with preview in case the domain changes at some point).
When the varnish server was first put in place we had issues with the preview images, that was eventually fixed in line with the documented way, however there was an undocumented method as well (/preview) which I didn’t think about.
Un-cached preview images cause a small load on the server as they are generated from the larger image, however, after the first generation they are cached and so not an issue, I am not sure a URL ending with /preview would actually be cached though.
I didn’t change anything to stop it working in the first place, but am hesitant to try fixing it again for the following reasons.
- It’s not the documented method
- If it doesn’t cache the image properly it would be a massive issue as we handle over 1.5 billion requests a month, if even 0.5% of that is to /preview that’s over 7.5 million requests a month and it’s unlikely the server would be able to cope.
- When the correct URL is eventually used the server might initially struggle as it is, no point doubling the amount of images it’s trying to cache
- We have also had 1 report of the wrong image being returned, but no one else saw that, so I’m not sure if it was a local caching issue, but if anyone else sees this please let us know in the IRC channel (Community / Chat With Us)
Good to know! Thanks for the update, Kode! 🙂
The undocumented method 301 redirects to the correct method now so it shouldn’t cause any headaches