Make WordPress Core

Opened 16 years ago

Last modified 18 months ago

#6814 assigned enhancement

Async media crunching

Reported by: matt's profile matt Owned by: adamsilverstein's profile adamsilverstein
Milestone: Future Release Priority: normal
Severity: normal Version: 2.5
Component: Upload Keywords: blessed dev-feedback needs-patch
Focuses: performance Cc:

Description

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.

Attachments (2)

capture.png (12.0 KB) - added by johnbillion 12 years ago.
wp_trac_thumbslater_6814.php (3.9 KB) - added by ramon fincken 5 years ago.
our_thumbnails-later_php_file.php

Download all attachments as: .zip

Change History (29)

#1 @tellyworth
16 years ago

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.

#2 follow-up: @endolith
16 years ago

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.

#3 in reply to: ↑ 2 @Otto42
16 years ago

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.

#4 @Denis-de-Bernardy
15 years ago

  • Component changed from Administration to Media

#5 @Denis-de-Bernardy
15 years ago

  • Component changed from Media to Upload

#6 @ryan
14 years ago

  • Milestone changed from 2.9 to Future Release

#7 in reply to: ↑ description @johnbillion
12 years ago

  • Keywords close added

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.

@johnbillion
12 years ago

#8 @SergeyBiryukov
12 years ago

  • Milestone Future Release deleted
  • Resolution set to duplicate
  • Status changed from new to closed

#9 @johnbillion
11 years ago

  • Keywords close removed
  • Resolution duplicate deleted
  • Status changed from closed to reopened

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

#10 @SergeyBiryukov
11 years ago

  • Milestone set to Awaiting Review

#11 @nacin
11 years ago

  • Milestone changed from Awaiting Review to 3.5

#12 @bpetty
11 years ago

  • Keywords punt added
  • Milestone changed from 3.5 to Future Release

Discussed punting this in IRC during scrub.

#13 @SergeyBiryukov
11 years ago

  • Keywords punt removed

#14 @matt
11 years ago

  • Owner changed from tellyworth to koop
  • Status changed from reopened to assigned

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

#15 @matt
11 years ago

  • Owner changed from koop to koopersmith

#16 @bpetty
11 years ago

  • Cc bpetty added

#17 @bpetty
10 years ago

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).

#18 @SergeyBiryukov
9 years ago

#31807 was marked as a duplicate.

#19 @ramon fincken
5 years ago

  • Focuses performance added
  • Keywords has-dev-note added

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 ?

This ticket was mentioned in Slack in #core-media by ramonfincken. View the logs.


5 years ago

#21 @azaozz
5 years ago

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 :)

#22 @ramon fincken
5 years ago

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
5 years ago

our_thumbnails-later_php_file.php

#23 @ramon fincken
5 years ago

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.

Last edited 5 years ago by ramon fincken (previous) (diff)

#24 @adamsilverstein
2 years ago

  • Owner changed from koopersmith to adamsilverstein

#25 follow-up: @mukesh27
21 months ago

  • Keywords has-patch dev-feedback added

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.

#26 in reply to: ↑ 25 @azaozz
21 months ago

  • Keywords needs-patch added; has-dev-note has-patch removed

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".
  1. 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.
  1. 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.

Last edited 21 months ago by azaozz (previous) (diff)

This ticket was mentioned in Slack in #core-media by adamsilverstein. View the logs.


18 months ago

Note: See TracTickets for help on using tickets.