On 4/24/09 10:32 AM, Roan Kattouw wrote:
> 2009/4/24 Chad<innocentkil...@gmail.com>:
>> 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

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to