On 4/24/09 10:32 AM, Roan Kattouw wrote:
2009/4/24 Chad<innocentkiller(a)gmail.com>om>:
All true. The images should not be rethumb'd
unless
resolution changes, a new version is uploaded, or the
cache is otherwise purged.
Repeat: this is what we do already (not sure if
that's what you're
trying to say, but "should" implies differently).
Just to summarize the current state, here's the default MediaWiki
configuration workflow:
* During page rendering, MediaWiki checks if a thumb of the proper size
exists.
* if not, we resize it synchronously on the same server (via GD or
shell out to ImageMagick etc)
* an <img> pointing to the file is added to output
* The web browser loads up the already-rendered image file in the page.
Here's the behavior variant we have on Wikimedia sites:
* During page rendering, we make an <img> pointing to where the
thumbnail should be
* The web browser requests the thumbnail image file
* If it doesn't exist, the upload web server proxies the request [1]
back to MediaWiki, running on a subcluster which handles only thumbnail
generation
* MediaWiki resizes it synchronously via shell out to ImageMagick
* The web server serves the now-completed file back to the client,
and it's now on disk for the next request
[1]
http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/upload-scripts/
This prevents slow or broken thumbnailing operations from bogging down
the *main* web servers, but if it's not reasonably fast we still have
difficulties:
* No placeholder image -- browser just shows a nice blank box
* Multiple requests will cause multiple attempts to resize at once,
potentially eating up all CPU time/memory/tmp disk space on the
thumbnailing cluster
So if we've got, say, a 50 megapixel PNG or TIFF high-res scan, or a
giant animated GIF which is very expensive to resize, we don't have a
good way of producing a thumbnail on a good schedule. It'll either time
out a lot every time it changes, or just never actually complete.
If we have a way to defer things we know will take longer, and show a
placeholder until it's completed, then we can use those things more
reliably.
One suggestion that's been brought up for large images is to create a
smaller version *once at upload time* which can then be used to quickly
create inline thumbnails of various sizes on demand. But we still need
some way to manage that asynchronous initial rendering, and have some
kind of friendly behavior for what to show while it's working.
-- brion