Roan Kattouw wrote:
The problem here seems to be that thumbnail generation times vary a lot, based on format and size of the original image. It could be 10 ms for one image and 10 s for another, who knows.
yea again if we only issue the big resize operation on initial upload with a memory friendly in-place library like vips I think we will be oky. Since the user just waited like 10-15 minutes to upload their huge image waiting an additional 10-30s at that point for thumbnail and "instant gratification" of seeing your image on the upload page ... is not such a big deal. Then in-page use derivatives could predictably resize the 1024x786 ~or so~ image in realtime again instant gratification on page preview or page save.
Operationally this could go out to a thumbnail server or be done on the apaches if they are small operations it may be easier to keep the existing infrastructure than to intelligently handle the edge cases outlined. ( many resize request at once, placeholders, image proxy / deamon setup)
AFAICT this isn't about optimization, it's about not bogging down the Apache that has the misfortune of getting the first request to thumb a huge image (but having a dedicated server for that instead), and about not letting the associated user wait for ages. Even worse, requests that thumb very large images could hit the 30s execution limit and fail, which means those thumbs will never be generated but every user requesting it will have a request last for 30s and time out.
Again this may be related to the use of unpredictable memory usage of image-magic when resizing large images instead of a fast memory confined resize engine, no?