Async media crunching

[matt]

The upload part of the new multi-uploader is pretty nice now, but it blocks on the "crunching" phase, which can sometimes take 20-60 seconds, I assume to create medium thumbnails and such.

The crunching part of the upload should not block the next file beginning the upload process, it should happen asynchronously with the rest of the process.

[tellyworth]

I'm not sure how common it is, but in my testing a good part of the 'Crunching' time is actually the final part of the file upload. It seems that swfupload triggers the 100% progress event (which is what causes Crunching to be displayed) when it begins sending the final chunk of the upload, rather than when it finishes sending it. I don't know of a solution to this.

In other words, the time spent creating thumbnails is only a fraction of the Crunching time, and might be negligible. Some basic logging with microtime() in async-upload.php would confirm it.

If it turns out thumbnail creation does take a significant amount of time, then yes, it should be done asynchronously.

[endolith]

Thumbnail and medium size image creation should not be done on upload at all. They should be created only when called for, so that they always reflect the size settings in Miscellaneous.

[Otto42]

Replying to endolith:

Thumbnail and medium size image creation should not be done on upload at all. They should be created only when called for, so that they always reflect the size settings in Miscellaneous.

-1. Highly disagree. This would add a ton of CPU time, as the image would need to be resized on every call to it, basically. Either that or it leaves tons of old files lying around every time you change the image sizes.

Furthermore, I don't think that changing a setting somewhere should instantly change the content/size of all the images in all your old posts.

[johnbillion]

Replying to matt:

The crunching part of the upload should not block the next file beginning the upload process, it should happen asynchronously with the rest of the process.

This no longer happens since we switched to Plupload. Subsequent files begin uploading while the previous file is crunching.

[SergeyBiryukov]

#18206

[johnbillion]

azaozz has confirmed this uploads are still synchronous. There is JS/UI lag after a file finishes crunching, giving the impression of async uploads.

[bpetty]

Discussed punting this ​in IRC during scrub.

[matt]

Let's put this one in 3.6 early, it's silly that four years later we still haven't addressed this.

[bpetty]

Now that Plupload 2.1 had just been merged, this ticket is back on the table for a review.

I'm sure we don't have the time to push it before beta 3.9, certainly not without a patch in the next day or two, but worth mentioning since the Plupload update (#25663).

[SergeyBiryukov]

#31807 was marked as a duplicate.

[ramon fincken]

Stepping in on this one .. we have some code that we ship at all our customers' installs, it will temporary remove the extra image sizes. Therefore no extra images will be created based on the original upload. It sets a meta flag on the uploaded item.

On each WP call, except a new upload the thumbs will be created.
A small snippet of this part:

<?php
$sql = $wpdb->prepare( 'SELECT post_id FROM '. $wpdb->postmeta . ' WHERE meta_key = %s LIMIT %d', $this->thumbslaterkey, $this->batch_limit ); 
foreach( $wpdb->get_results( $sql ) as $thumbs_later ) { 
  if( $this->init( $thumbs_later->post_id ) ) { 
     delete_post_meta( $thumbs_later->post_id, $this->thumbslaterkey ); 
  } 
}

It is not said that this postmeta is the best in terms of optimization. A non-autoloaded option could also be used for this. However we use a batch limit in the SELECT clause.

Are you interested in the whole code or the pseudocode ?

[azaozz]

Thanks @ramon-fincken, this sounds like something we can use/learn from on #40439? (See the patch there too, it saves the image meta after each sub-size is created instead of waiting for all to be done).

A pseudo code should be good for now I think :)

[ramon fincken]

Ok so here we go .. sorry about no comments in code. We ship this at every customer as we see loads of folders from their local machines are just dragged and dropped to the media upload.

It is used as as MU-plugin. Boot it by:

        include_once '/YOURDIR/thumbnails-later/managedwphosting_thumbnails_later.php';
        add_action('init' , 'ManagedWPHostingRegenerateThumbnails_Later');

The only thing I needed due to not be touching Core on this one is the flag MWP_THUMBSLATER_FLAG (defined). The define is just an extra pre-caution, I think it could be removed.

So: it will temporary remove the extra image sizes. (super low prio action flag 999) Therefore no extra images will be created based on the original upload. It sets a meta flag on the uploaded item.
On each WP call, except a new upload the thumbs will be created.

It is not said that this postmeta is the best in terms of optimization. A non-autoloaded option could also be used for this. However we use a batch limit in the SELECT clause.

Parts of the code are based on the Regenerate thumbnails plugin by @viper007bond
When checking the code right now I see that there might be a small hickup in the SQL query. What if the attachment is in trash? Not a big thing but stil.. waste of perfomance.

If you have any questions feel free to ask now or at WCEU Berlin next month. I will be present at the contributor day.

I will attach the PHP MU-plugin file in a sec.

[ramon fincken]

our_thumbnails-later_php_file.php

[ramon fincken]

Update: postmeta is better than an option

Update2:

if( $this->init( $thumbs_later->post_id ) ) { 
     delete_post_meta( $thumbs_later->post_id, $this->thumbslaterkey ); 
  }

Update3:
this should be removed

                if ( $this->fullsizepath ) {
                                return $this->fullsizepath;
                        }

might need an else to delete the meta key (when errors) else you will keep looping over the very same IDs over and over again due to them beeing in error.

[mukesh27]

Hi there!

Since the ticket was created and the related discussion took ~14 years, do we think we can add/fix it in the upcoming WordPress release?

If this feature improves the image upload process then it will surely help sites that use many images. As @ramon-fincken comments, it also improves its performance for it.

has-patch and dev-feedback keywords were added so other folks can check and provide patches for it.

[azaozz]

Replying to mukesh27:

do we think we can add/fix it in the upcoming WordPress release?

Would be great but there are a few "undecided problems" here.

1. Certain image sub-sizes are typically needed immediately after uploading an image. Most common case is when a user adds an image to a post. The editor expects the proper/correct sub-size to be available as soon as the image has finished "crunching".

2. The "how to trigger making of sub-sizes" is still undecided. The above patch makes them on the next request however that just moves the "bottleneck" of creating sub-sizes (can be in excess of 30 seconds) from the upload request to the next page load request. Not sure that's a good idea especially on bigger/busier sites where the next request is most likely to be on the front-end.

3. Apart from creating image sub-sizes this patch would likely have to look at/handle converting uploaded images to WEBP format. Think there is another ticket specifically for this but likely the tickets should be merged as the solution would probably be the same.

The negative effect from point 1 can probably be fixes to a large extend by creating just two sub-sizes on uploading an image, the large and thumbnail sizes. That will cover most use cases. In the rest of the cases WP will fall back on using one of these sub-sizes until the rest are created (that functionality already exists). As a side-note this won't work well for custom sub-sizes that crop the image.

For point 2 there are several options. The above approach can be changed a bit so only one or two sub-sizes are created on each request. That may become a problem after uploading a lot of images (making a big gallery) on a site that sees a little traffic, but would be better than "locking down" the site for seconds.

Another approach may be to try to implement the "selective sub-size creation method". Then only image sub-sizes that are requested will be created. Good part of it is that it will reduce disk use for sub-sizes, bad part is it would slow-down front-end image load times when the needed sub-size(s) do not exist yet. That slow-down may be quite significant when loading a gallery. Also thinking this may be affected by HTTP/2 and may result in PHP running out of memory or timing out when a lot of sub-sizes have to be created.

As WEBP is supported by virtually all newer browsers thinking it may be worth it to convert all uploaded images to .webp on uploading. This would be handled in another ticket. If it's too early yet, seems WP will have to generate two formats of sub-sizes, original and WEBP. That can be handled in this ticket.