I think I need more context. Is this what you're saying? - we want to use less storage space - images we are generating and caching for not-Wikipedia should be the first to go - we assume weird sizes are from not-Wikipedia. So let's cache them for less time - except, that doesn't work, because of tall images - so maybe we should change the image request format?
If this is accurate I have a few questions: - If you want to prioritize Wiki[mp]edia thumbnails, why not use the referrer header instead? Why use the width parameter to detect this? - Are we sure we'll improve overall performance by evicting certain files from cache quicker? Why not trust the LRU cache algorithm? On 8/13/14, 1:36 AM, Gilles Dubuc wrote: > Currently the file page provides a set of different image sizes for > the user to directly access. These sizes are usually width-based. > However, for tall images they are height-based. The thumbnail urls, > which are used to generate them pass only a width. > > What this means is that tall images end up with arbitrary thumbnail > widths that don't follow the set of sizes meant for the file page. The > end result from an ops perspective is that we end up with very diverse > widths for thumbnails. Not a problem in itself, but the exposure of > these random-ish widths on the file page means that we can't set a > different caching policy for non-standard widths without affecting the > images linked from the file page. > > I see two solutions to this problem, if we want to introduce different > caching tiers for thumbnail sizes that come from mediawiki and > thumbnail sizes that were requested by other things. > > The first one would be to always keep the size progression on the file > page width-bound, even for soft-rotated images. The first drawback of > this is that for very skinny/very wide images the file size > progression between the sizes could become steep. The second drawback > is that we'd often offer less size options, because they'd be based on > the smallest dimension. > > The second option would be to change the syntax of the thumbnail urls > in order to allow height constraint. This is a pretty scary change. > > If we don't do anything, it simply means that we'll have to apply the > same caching policy to every size smaller than 1280. We could already > save quite a bit of storage space by evicting non-standard sizes > larger than that, but sizes lower than 1280 would have to stay the way > they are now. > > Thoughts? > > > _______________________________________________ > Multimedia mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/multimedia -- Neil Kandalgaonkar (| <[email protected]>
_______________________________________________ Multimedia mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/multimedia
