Problem/Motivation

Migrating media items can be very slow compared to handling other entities, particularly if you're using a remote file system (s3fs). The reason is that multiple times it's fetching the width and height of the source image.

The issue can be mitigated by providing the actual width and height for the image field and thumbnail at the time of import if available and by enabling queue_thumbnail_downloads. Yet, imports are still not as fast as they should be, because reading metadata calls imageFactory and creates an Image object. This will always fetch image dimensions regardless of whether width and height of the image are actually being needed (i.e. if it's just asking for the thumbnail alt text).

Steps to reproduce

Create a migration with imports media entities and run drush migrate:import (in our scenario we import nodes and images form an RSS feed).

Proposed resolution

Simply move:

$image = $this->imageFactory->get($uri);

...so it's only called when width or height is specifically requested. Don't call it if it's just the thumbnail_urior thumbnail_alt_value.

Remaining tasks

Maybe needs automated tests.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

phma created an issue. See original summary.

heddn’s picture

Status: Active » Reviewed & tested by the community
Issue tags: +Performance, +migrate

I don't think we can really do extra testing here then what is already available. And even on local file destinations, this would help a fair amount with the migration speed.

  • larowlan committed e396c25 on 9.2.x
    Issue #3215198 by phma: Thumbnail updates read width and height from...
  • larowlan committed 9edbbe5 on 9.3.x
    Issue #3215198 by phma: Thumbnail updates read width and height from...
larowlan’s picture

Status: Reviewed & tested by the community » Fixed
Issue tags: +Bug Smash Initiative

Committed 9edbbe5 and pushed to 9.3.x. Thanks!

As the risk of disruption is low here, backported to 9.2.x

alexpott’s picture

Resaving as the issue is still appearing in the rtbc queue for some reason

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.