Magento 2

Magento 2 Media Sync Performance Bottleneck: Why `media-gallery:sync` Scans Excluded Files

At Shopping Mover, we understand that efficient media management is paramount for any thriving e-commerce store. Magento 2, being a robust platform, offers various tools to handle digital assets. One such critical command is media-gallery:sync, designed to synchronize your media storage with the database, ensuring consistency and proper indexing of your product images, WYSIWYG content, and other visual assets.

Inefficient media scanning process in Magento 2, where excluded files are still processed.
Inefficient media scanning process in Magento 2, where excluded files are still processed.

The Unexpected Performance Hit: Scanning Excluded Directories

However, a recent GitHub issue (#41422), meticulously detailed by user lbajsarowicz, has shed light on a significant performance bottleneck within this command, particularly for stores with extensive media libraries. The core of the problem lies in how the media-gallery:sync command processes files.

Instead of intelligently scanning only relevant directories and respecting exclusion rules from the outset, the command exhibits a behavior that can severely impact performance and memory consumption. Specifically, the issue highlights that the command recursively discovers every file and directory under pub/media. This includes subtrees that are explicitly excluded from synchronization, such as cache, import, or temporary directories. Only after compiling and sorting this complete, exhaustive list of paths does it then apply the exclusion rules and begin yielding synchronization batches.

Deep Dive into the Technical Flaw

The technical root of this inefficiency is pinpointed in the Magento 2.4-develop codebase. According to the issue, app/code/Magento/MediaGallerySynchronization/Model/FetchMediaStorageFileBatches.php:90 calls readRecursively() for the media root before isApplicable() or any batch yield. Furthermore, lib/internal/Magento/Framework/Filesystem/Directory/Read.php:158 collects relative paths and globally sorts the full result at line 168. This means the system builds a comprehensive, sorted list of *all* files and directories within pub/media before any filtering based on the configured allowed media gallery folders (like catalog/category or wysiwyg) takes place.

The current MediaGallery\Model\Directory\IsExcluded service is designed to identify and exclude paths, but its application comes too late in the process. The system has already invested significant resources in discovering and storing paths for files it will ultimately ignore.

Impact on Large Magento Stores and Adobe Commerce Deployments

Imagine a Magento store, especially an Adobe Commerce instance, with hundreds of thousands of product images, many of which reside in cache or temporary folders within pub/media. While these files are correctly excluded from the final synchronization, the current implementation forces the system to read and store paths for all of them initially. This "pre-scan" of irrelevant files leads to:

  • Increased Initial Scan Latency: The time taken for the first synchronization batch to become available is significantly extended. The issue author measured a median of 152 ms just for the initial scan and path collection, before any of the 101 legitimate images were processed, when 90,000 files were present in an excluded catalog/product/cache directory.
  • Higher Memory Consumption: Storing the complete list of paths for potentially hundreds of thousands or even millions of files demands substantial memory. The example provided showed 32.6 MB allocated for the scan alone, growing with the number of files. This can push servers to their limits, especially in shared hosting environments or during resource-intensive operations.
  • Degraded CLI Performance: For developers and administrators, this translates to slower execution of the media-gallery:sync command, impacting deployment pipelines, cron job efficiency, and overall server resource utilization.
  • Resource Strain: On large-scale Adobe Commerce setups, where media assets can easily number in the millions, this inefficiency can lead to significant CPU and I/O spikes during synchronization, potentially affecting other critical processes.

In e-commerce, every millisecond counts. Slow CLI commands can delay deployments, consume valuable server resources, and even lead to timeouts during critical maintenance windows. This issue directly impacts the operational efficiency and scalability of Magento 2 stores.

The Expected Behavior: Efficient, On-Demand Scanning

The ideal scenario, as outlined in the issue, would be for the synchronization process to produce batches while reading directories on demand. It should avoid descending into subtrees that the existing exclusion service cannot accept from the outset. Increasing the number of files in excluded subtrees should not require reading and storing all of their paths before the first batch. This would ensure that only relevant paths are processed, significantly reducing latency and memory footprint.

Shopping Mover's Perspective and Recommendations

As experts in Magento migrations and performance tuning, we frequently encounter scenarios where inefficient media handling becomes a major bottleneck. This issue highlights the importance of not just having robust features, but also ensuring their underlying implementation is optimized for real-world, large-scale e-commerce operations.

While we await an official fix from the Magento core team, there are best practices to mitigate the impact of this issue:

  • Regularly Clean pub/media: Implement a routine to clean up truly temporary, cache, or unused files from your pub/media directory. While the sync command still scans, fewer files mean less overhead.
  • Optimize Folder Structure: Ensure your pub/media folder structure is as lean and organized as possible, minimizing unnecessary subdirectories.
  • Leverage Robust Hosting: Ensure your Magento 2 environment has ample memory and fast I/O capabilities to handle the temporary load, especially if you have a vast media library.
  • Monitor Sync Execution: Regularly monitor the execution time and resource consumption of your media-gallery:sync cron jobs. This can help identify when the issue is severely impacting your system.
  • Consider External Media Storage (for delivery): While not a direct fix for the sync command's internal logic, using a Content Delivery Network (CDN) or external storage like AWS S3 for media delivery can offload `pub/media` access during frontend requests, improving overall site performance.
  • Contribute to the Fix: For developers, contributing to the Magento Open Source project by proposing a solution or fix for this GitHub issue (#41422) would be a valuable community contribution.

Addressing such fundamental performance issues is key to maintaining a scalable and efficient Magento 2 store. At Shopping Mover, we are committed to helping our clients navigate these complexities, ensuring their e-commerce platforms run at peak performance, whether through migrations, optimizations, or ongoing support.

Share:

Start with the tools

Explore migration tools

See options, compare methods, and pick the path that fits your store.

Explore migration tools