DEV Community: Magevanta

Magento 2 Linux Server Tuning: Kernel, Filesystem & I/O Settings That Actually Matter

Magevanta — Sun, 23 Aug 2026 09:01:45 +0000

Most Magento 2 performance work stops at the application layer: PHP-FPM pools, Nginx config, MySQL buffers, Redis, Varnish. That's where the visible wins are. But underneath all of it sits the operating system, and on a stock Ubuntu or Debian install it's running kernel, filesystem and I/O defaults that were never designed for an application that reads and writes thousands of small files and pounds a database with mixed random I/O every second.

This guide covers the OS-level settings that actually move the needle for Magento 2: filesystem mount options, I/O scheduler, memory tuning (swappiness, dirty pages, Transparent Huge Pages), CPU governor, file descriptor limits and the tuned profile. Everything is verifiable, and most changes are two lines in sysctl.conf plus a remount.

Why the OS layer matters for Magento

Magento 2's workload profile is specific:

Thousands of small files. pub/static, var/view_preprocessed, generated/ and pub/media add up to hundreds of thousands of inodes. Every static content deploy rewrites tens of thousands of them.
Mixed random I/O on MySQL. The catalog_product_index_price rebuild, order grid indexing and log cleanup all do heavy sequential-ish scans, while checkout does small random reads. Your storage handles both at once.
Bursty cache writes. Redis writes, session files (if filesystem-backed), Varnish cache — all bursty, all latency-sensitive.
Page cache dependency. A single framework-level cache miss cascades into dozens of MySQL round-trips. The OS can't fix that, but it decides how fast those disk-backed misses resolve.

If your stack is already well-tuned and your bottleneck is still I/O or latency spikes under load, the OS layer is the next place to look.

1. Filesystem: ext4 vs XFS and mount options

The filesystem choice matters less than most people think — modern ext4 and XFS both handle Magento workloads fine. What matters more is how they're mounted.

Minimal mount options that are safe on ext4 for a Magento server:

/dev/sdb1  /var/www  ext4  defaults,noatime,nodiratime,errors=remount-ro  0 2

noatime — the big one. Every file read updates the atime (access time) by default, which means a metadata write on every read. Magento reads the same static files and opcache-scanned PHP files thousands of times a day. Disabling atime eliminates a whole class of unnecessary writes. nodiratime is redundant on modern kernels when noatime is set, but harmless to include.
commit=60 (ext4) — the journal commit interval. Default is 5 seconds; raising it to 30–60 reduces journal write pressure on busy data volumes. Only for non-critical data partitions; don't do this on a volume whose recent writes you'd hate to lose.
discard vs fstrim — on SSDs/NVMe, periodic fstrim (via cron or systemd timer) is safer than the discard mount option, which can cause I/O stalls on some controllers. Use fstrim -av weekly.

Verify:

mount | grep -E 'var/www|pub'
# "noatime" should be in the options list

A note on var/ and generated/: some teams put var/cache, var/session or generated/ on tmpfs (RAM disk) to eliminate disk I/O entirely. This works and is fast, but it's volatile: a reboot empties them, so var/cache and generated/ must be rebuildable in your deploy (they are — cache is warmable, generated code comes from bin/magento setup:di:compile). Never put anything irreplaceable there, and size it carefully (a generated/ dir can exceed 1–2 GB on big catalogs). For most setups, a fast NVMe with noatime is the safer 90% of the win.

2. I/O scheduler: know what you're running on

The I/O scheduler decides how requests are queued to the disk. Since kernel 5.x on NVMe, the default is none (noop), which is correct — NVMe devices with deep hardware queues don't need software scheduling. On SATA SSDs and HDDs, mq-deadline is the right choice.

Check with:

cat /sys/block/sda/queue/scheduler

If it shows [none] on a SATA SSD or HDD, switch to mq-deadline at boot via a udev rule:

# /etc/udev/rules.d/60-iosched.rules
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/scheduler}="mq-deadline"

What really matters for Magento is not letting the scheduler starve your database. If MySQL, Redis and the web server share one disk, heavy batch jobs (reindex, log cleanup, static content deploy) can saturate the queue and push checkout latency through the roof. Two mitigations:

Run batch jobs with ionice: ionice -c 2 -n 7 bin/magento indexer:reindex — best-effort class, lowest priority, so the queue still services foreground reads.
If you can, split storage: database on one volume, pub/media + var/ on another. This is the single most effective I/O isolation you can do on a single server.

3. Memory: swappiness, dirty pages and THP

Three settings that are consistently wrong on stock installs for Magento + MySQL servers.

vm.swappiness — controls how eagerly the kernel swaps anonymous memory. Default is 60, which is far too aggressive for a server with a large page cache. For database servers, vm.swappiness = 10 is the classic recommendation; for Magento with Redis caching, 10 is a good middle ground (Redis' own maxmemory policy handles eviction, and you don't want Redis pages swapped out). On systems with plenty of RAM, 0–10.

# /etc/sysctl.d/99-magento.conf
vm.swappiness = 10

Dirty page writeback — when the kernel accumulates too many dirty pages, it flushes them in bursts, causing I/O stalls that show up as MySQL latency spikes. A known-good pairing for DB servers:

vm.dirty_ratio = 15
vm.dirty_background_ratio = 5

dirty_background_ratio starts background writeback at 5% dirty memory, dirty_ratio forces synchronous flush at 15%. The defaults (10/20 on many distros) let dirtiness climb higher before acting, producing bigger, nastier bursts. On a server with 64 GB RAM these numbers mean MySQL's double-write buffer and redo log flushes stay smooth instead of queuing behind a wall of page-cache writes.

Transparent Huge Pages (THP) — the single most famous OS-level fix in the MySQL world. THP is enabled by default (always), and while it helps some workloads, for MySQL it's documented to cause severe latency issues: memory is allocated in 2 MB huge pages, and during defragmentation the kernel stalls threads waiting for page compaction. Every major distro's MySQL docs say the same thing: set it to madvise or never.

echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

To make it persistent:

# /etc/systemd/system/disable-thp.service
[Unit]
Description=Disable Transparent Huge Pages
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo never > /sys/kernel/mm/transparent_hugepage/enabled && echo never > /sys/kernel/mm/transparent_hugepage/defrag'

[Install]
WantedBy=multi-user.target

Verify: cat /sys/kernel/mm/transparent_hugepage/enabled should show [never] or [madvise]. This alone has fixed "random" MySQL latency spikes on more Magento servers than I can count.

4. CPU governor: stop letting the kernel downclock your store

On bare metal and VPS with exposed CPU frequency scaling, the default powersave/ondemand governor downclocks cores aggressively, which shows up as slow PHP execution — exactly the symptom people blame on "Magento being slow." For a server, set it to performance:

cpupower frequency-set -g performance   # or:
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Persist via tuned (below) or cpupower.service. Note: on most cloud VPS (AWS, DigitalOcean, Hetzner) the governor is not exposed or already pinned — check cpupower frequency-info and skip this if it's not settable.

5. File descriptor limits: the silent 1024-cap

PHP-FPM, Nginx, Elasticsearch/OpenSearch, Redis and MySQL all need more than the default 1024 soft file descriptor limit when the store is busy. Symptoms of hitting it: "Too many open files" in php-fpm.log, MySQL Can't open file errors, ES red logs for no obvious reason.

Raise the system limit and per-service limits:

# /etc/sysctl.d/99-magento.conf
fs.file-max = 2097152

And in each systemd unit (PHP-FPM, Elasticsearch, Redis, MySQL), add:

[Service]
LimitNOFILE=65535

This is one of those settings that never shows up in app-level profiling but is a classic cause of "random" errors at peak traffic. If you see these errors only during Black Friday / flash-sale spikes, check this first.

6. Just use tuned: `throughput-performance`

Instead of hand-rolling all of this per distro flavor, install tuned and apply the throughput-performance profile, which sets the sane defaults for servers (governor to performance, swappiness to 10, THP to madvise, noatime-ish behavior):

apt install tuned
tuned-adm profile throughput-performance
tuned-adm active   # verify

You still want to explicitly set vm.dirty_* and disable THP for MySQL yourself (the profile only sets THP to madvise; many DBAs prefer never), but tuned gives you a solid, persistent baseline in one command.

7. What to measure after applying

Every change here should be justified by a before/after. The tools that matter:

iostat -x 2 — look at %util, await, svctm. If await is high on MySQL's volume during reindex, your I/O layer is the bottleneck, not the query.
vmstat 2 — si/so column (swap in/out) should be near zero. If you see steady swapping, you're undersized on RAM or swappiness is wrong.
MySQL SHOW GLOBAL STATUS for Innodb_buffer_pool_wait_free — if this counter climbs, InnoDB is waiting for page flushes under memory pressure; dirty-page tuning and buffer pool sizing are your lever.
dmesg / journalctl -k for "stall" or THP compaction messages — smoking gun for THP-related latency.

Apply changes one at a time, keep the sysctl file small and commented, and re-run your load test (k6, siege, or a replay of your slow-query log) after each change.

The checklist

Here's the full set, condensed — safe on any Ubuntu/Debian Magento 2 server:

# /etc/sysctl.d/99-magento.conf
vm.swappiness = 10
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5
fs.file-max = 2097152

Remount data partitions with noatime (verify with mount).
I/O scheduler: none on NVMe, mq-deadline on SATA/HDD.
THP → never, persisted via systemd unit.
tuned-adm profile throughput-performance (+ CPU governor to performance where exposed).
LimitNOFILE=65535 on PHP-FPM, ES, Redis, MySQL systemd units.
ionice your reindex/cron batch jobs; separate MySQL from media/var volumes if possible.

Skip-worthy: swappiness below 10 (no benefit, hurts page cache), noatime on commit=0 journal tricks, aggressive vm.dirty_expire_centisecs micro-tuning, and any kernel compile-level "optimizations" you found in a 2015 blog post. The list above is the tested 90%.

The honest bottom line

The OS layer is where the last 5–10% of a Magento 2 server's performance lives — but only after the app layer is done. If your MySQL slow-query log is full, your FPM pm.max_children is wrong, or your Varnish hit rate is under 90%, fix those first. When you've done that and the server still feels "laggy under load" without an obvious app-level cause, the settings above — especially THP, swappiness/dirty ratios and I/O scheduler — are where the hidden latency actually lives. They're free, they're reversible, and unlike most Magento "performance tips," they're verifiable with three commands.

Magento 2 Product Reviews Performance: The Hidden Cron & N+1 Bottleneck

Magevanta — Sat, 22 Aug 2026 09:03:35 +0000

Product reviews look innocent. A star rating in the listing, a list of comments on the product page, an admin grid to moderate them. What could possibly be slow about that?

Plenty. Reviews are one of those Magento subsystems where the visible surface is small but the hidden machinery is disproportionate: a full aggregation cron that recomputes every rating from scratch every 15 minutes, per-product summary queries that turn a 30-product listing into 30 extra SQL round-trips, and an admin grid that joins product names across the whole catalog. On stores with a few hundred thousand reviews — which takes surprisingly little time to accumulate — reviews quietly become one of the top five slow things in your stack.

This guide walks through the three real bottlenecks (the cron, the N+1, the grid), what to measure, and the fixes that actually work.

How reviews are stored

Before optimizing anything, know the tables. Magento 2 spreads a single "review" across four tables:

review — the review itself: entity_pk_value (product id), entity_id (review entity type), status_id (1 = approved, 2 = pending, 3 = not approved), created_at.
review_detail — the localized content: title, detail text, nickname, customer id, per store view. This is the table that grows fastest on multi-store setups, because a review gets one row per store view.
rating_option_vote — the raw star votes, one row per rating per review. percent, value, review_id, entity_pk_value.
review_entity_summary — the pre-aggregated numbers per product per store: reviews_count, ratings_summary. This is what the storefront actually reads, so it's the table that must stay fast.

The design is fine — the problem is how the aggregated table gets maintained.

The 15-minute aggregation cron (the real killer)

Magento ships a cron job called aggregate_reviews (Magento\Review\Cron\AggregateReviews), scheduled every 15 minutes in core. For every store view, it:

Deletes all rows from review_entity_summary and rating_option_vote_aggregated for that store,
Recomputes them from scratch by joining rating_option_vote against review (filtered on approved status),
Re-inserts the results.

That's a full recompute of every rating in the store — not an incremental update. On a store with 200k reviews and 500k votes, this single job is a multi-hundred-million-row scan executed four times an hour, and it shows up in your slow-query log as a monster INSERT ... SELECT ... GROUP BY that runs for minutes. It also fires during business hours, right when you'd rather not have a heavyweight aggregating query competing with checkout traffic.

How to check if this is you:

-- longest aggregate runs in the last 7 days
SELECT job_code, status, scheduled_at, executed_at, finished_at,
       TIMESTAMPDIFF(SECOND, executed_at, finished_at) AS seconds
FROM cron_schedule
WHERE job_code = 'aggregate_reviews'
  AND executed_at > NOW() - INTERVAL 7 DAY
ORDER BY seconds DESC
LIMIT 10;

If you see runs of minutes, or overlaps (the next run starting before the previous finished — look for status = 'running' while a new row is scheduled), the job is a problem.

Fixes, in order of effort:

1. Move it off-peak. The schedule lives in app/code/Magento/Review/etc/crontab.xml. Don't patch core — override it in a small custom module or via a deployment script that rewrites the config. Moving the job from */15 * * * * to e.g. 5 */1 * * * (hourly) or even daily at 03:00 changes nothing for the storefront: review_entity_summary is only read after a cache refresh anyway, and a couple of hours of staleness on star ratings is invisible to customers. What you lose is nothing; what you gain is 90+ fewer full recomputes per day.

2. Batch it. If even one daily run is too heavy, write your own aggregator that processes products in chunks (e.g. 5,000 products per transaction) instead of one giant INSERT ... SELECT. Same math, no long locks, no temp-table spill to disk.

3. Reduce contention. Make sure the job runs in a cron pool with a dedicated PHP-FPM/CLI environment and enough tmp_table_size/max_heap_table_size — the aggregation is a textbook "create temporary table on disk" query when MySQL's in-memory temp table limit is too low.

The N+1 on listings and product pages

The storefront reads review_entity_summary, which is the good news — it's a small, indexed table. The bad news: many themes render star ratings in listings (category pages, related products, recently viewed, wishlist widgets), and the core Magento\Review\Block\Product\ReviewRenderer loads the summary per product. Thirty products → thirty SELECT ... FROM review_entity_summary WHERE entity_pk_value = ? queries per page view. Add a "recently viewed" strip with ratings and you're at 45–60 queries before anyone even looks at the product.

Worse is the product page with a review list: the toolbar, pagination count and each review's vote data all trip additional lookups on review, review_detail and rating_option_vote. On a product with 500 reviews you're now loading a lot of rows for a tab most visitors never open. (Core paginates at 10 per page — good — but the count query and the vote joins still run.)

The fix is preloading, not caching:

// In your listing block: collect product ids first, then load ALL summaries in ONE query
$productIds = array_map(fn($p) => $p->getId(), $products);

/** @var \Magento\Review\Model\ResourceModel\Review\Summary\Collection $summaries */
$summaries = $this->summaryCollectionFactory->create();
$summaries->addEntityFilter($productIds)          // batch: WHERE entity_pk_value IN (...)
          ->addStoreFilter($storeId)
          ->load();

$summaryMap = [];
foreach ($summaries as $summary) {
    $summaryMap[$summary->getEntityPkValue()] = $summary;
}

// Then feed each renderer instead of letting it query
foreach ($products as $product) {
    /** @var \Magento\Review\Block\Product\ReviewRenderer $renderer */
    $summary = $summaryMap[$product->getId()] ?? null;
    $renderer->setProduct($product);
    $renderer->setRatingSummary($summary ? $summary->getRatingSummary() : 0);
    $renderer->setReviewsCount($summary ? $summary->getReviewsCount() : 0);
    echo $renderer->toHtml();
}

One query for the whole page instead of one per product. This is the same pattern that fixes related products, wishlist and recently viewed — the block is the bottleneck, not the table.

For the review list on the product page: keep core's pagination, but lazy-load the list itself (an AJAX "load reviews" button) if your product pages carry hundreds of reviews. The star summary in the header is the part customers actually see; the full list can arrive on demand.

The slow admin grid

The admin "Reviews" grid (Magento\Review\Model\ResourceModel\Review\Product\Collection) joins the review tables against catalog_product_entity plus a store-scoped product name lookup. With hundreds of thousands of reviews, three things degrade:

Unfiltered grid loads — the count and first-page queries scan the whole review table; the entity_pk_value column is not meaningfully selective when the grid has no filter.
The product-name join — resolving names per store across a big catalog makes every grid refresh expensive.
Missing composite indexes — single-column indexes don't help WHERE status_id = ? AND entity_pk_value IN (...) style lookups.

Indexes worth adding (after testing on staging):

ALTER TABLE review
  ADD INDEX IDX_REVIEW_STATUS_ENTITY (status_id, entity_pk_value),
  ADD INDEX IDX_REVIEW_CREATED_AT (created_at);

ALTER TABLE review_detail
  ADD INDEX IDX_REVIEW_DETAIL_STORE (store_id);

ALTER TABLE rating_option_vote
  ADD INDEX IDX_RATING_VOTE_REVIEW (review_id);

Also: encourage your moderators to filter (pending status, date range, product) instead of paging through the full grid, and run a periodic cleanup of old not approved reviews to keep the table from growing with spam that nobody will ever moderate.

Cache behavior: review bursts are cache churn

A submitted review invalidates the product page's full-page cache tag (catalog_product_{id}) — Magento does this deliberately so the new rating shows up. That's correct behavior, but it has a scaling consequence: during a marketing push that generates hundreds of reviews per hour on a few hot products, those products' FPC entries keep getting invalidated and re-rendered, and every visitor pays for the re-render until the next hit warms it.

Mitigation options:

Accept slight staleness: reviews can lag a few minutes; the aggregation cron already introduces the same lag.
If bursts are a real pattern, an inline/ESI-style fragment for the review summary keeps the rest of the page cached while only the rating fragment re-renders.
Watch your Varnish hit-ratio dashboard during review-heavy campaigns — if the hot-product pages drop out of cache repeatedly, that's the symptom.

The checklist

Measure first: cron_schedule durations for aggregate_reviews, query count via the profiler on a category page with ratings, and the admin grid's load time unfiltered.
Reschedule the aggregation cron off-peak (hourly or daily) — zero storefront impact, big DB relief.
Batch the aggregation if a single run still takes minutes.
Preload summaries in listings with one batched addEntityFilter() collection instead of per-product queries.
Lazy-load long review lists on product pages.
Add the composite indexes for status/entity and vote lookups, after staging tests.
Keep the admin grid filtered and clean out never-approved spam rows.

Reviews are a social-proof feature with a hidden performance tax. None of these fixes change what customers see — they change what your database does four times an hour. That's the best kind of optimization: invisible, and worth more than a hundred milliseconds of TTFB tricks.

Magento 2 PHP 8.4 Upgrade: Real Performance Gains & a Safe Migration Checklist

Magevanta — Fri, 21 Aug 2026 09:02:58 +0000

Every Magento performance audit I do ends the same way: we spend weeks optimizing a custom module, fiddling with Varnish TTLs, shaving off a few milliseconds of TTFB — and the single biggest, cheapest win is still sitting untouched in php -v. Most stores run PHP 8.1 or 8.2 not because they need to, but because nobody scheduled the upgrade. Meanwhile each PHP minor release ships a few percent of free performance, better opcache behavior and lower memory usage.

This guide covers what PHP 8.4 actually gives a Magento 2 store, which Magento versions support it, and a pragmatic checklist to upgrade without burning a weekend fighting deprecation warnings.

What PHP 8.4 delivers (the honest version)

Before the features, the number that matters: measured on CMS-style workloads (which is what Magento is — object-heavy, I/O-bound PHP), PHP 8.4 is roughly 5–10% faster than 8.3, which itself was ~10% faster than 8.2, which was ~10–20% faster than 8.1 depending on the workload. Stacked up: 8.1 → 8.4 is often a 25–35% throughput improvement on the same hardware. No Redis tuning, no query optimization, no code changes — just a runtime swap.

Where does that come from?

Opcache improvements — better JIT tuning, faster hash tables, more aggressive opcode optimizations.
Reduced memory usage — PHP 8.4 continues the trend of lower per-request allocation, which matters more than raw CPU for Magento: FPM workers that use less memory per request can each serve more concurrent requests before pm.max_children becomes the wall.
Faster autoloading and startup — a meaningful slice of every Magento request is class loading and bootstrapping; the runtime-level gains compound with opcache preloading.
Incremental garbage collector (since 8.3, still relevant) — cycle collection no longer pauses the whole request, which smooths out latency spikes on long-running cron jobs and imports.

The honest caveat: don't expect a 30% TTFB drop on a cached page. If the page is served from Varnish or full-page cache, PHP barely runs. The gains show up on uncached pages, checkout (which is deliberately non-cacheable), admin operations, complex API calls, reindexing, imports and concurrent traffic. For a store with a warm cache, the win is capacity, not latency: the same server handles more checkout load during a flash sale. That's often worth more than a faster homepage.

JIT: why Magento mostly ignores it

PHP 8.0 introduced JIT, and every blog post since has asked whether Magento should enable it. Short answer: no, and 8.4 doesn't change that. JIT shines on CPU-bound pure-computation loops. Magento's request lifecycle is dominated by I/O (MySQL, Redis, filesystem, network) and object instantiation — precisely the workload where JIT overhead (memory for compiled traces, more complex opcache state) can even make things marginally slower.

The exception: if you run heavy CPU-bound PHP workloads — big product imports with lots of arithmetic, custom report generation, complex rule matching — you can A/B test opcache.jit=tracing in a staging environment and measure with a stopwatch rather than vibes. Default (off in FPM, and not enabled by Magento's config) remains the right production choice for the vast majority of stores.

What helps instead:

; php.ini — the boring wins that actually matter for Magento
opcache.enable=1
opcache.memory_consumption=512
opcache.validate_timestamps=0        ; in production only!
opcache.revalidate_freq=0
opcache.interned_strings_buffer=32   ; PHP 8.4 handles interned strings more efficiently
realpath_cache_size=4096K            ; filesystem-heavy Magento boot loves this
realpath_cache_ttl=600

Which Magento supports PHP 8.4

Compatibility matrix, as of writing:

Magento 2.4.7 and earlier: PHP 8.2 max. Do not force 8.4 on these — core code (and most extensions) will throw deprecations and fatals in places.
Magento Open Source / Adobe Commerce 2.4.8 (April 2025): first release with official PHP 8.4 support (also the release that moved to MariaDB 11.4 and OpenSearch 2.x defaults). EOL April 2028.
2.4.8-p1 and later patch releases: PHP 8.4 remains supported.

So the upgrade path is really: get to 2.4.8+, then move PHP. If you're still on 2.4.6-p5 or earlier, the PHP upgrade is a side effect of the Magento upgrade, and you should treat both as one project with a proper staging phase.

The upgrade checklist

1. Know what you're running

Before touching anything, inventory the runtime surface: PHP version on each node, FPM pool config, which web server talks to FPM, and the PHP binary used by bin/magento cron. Stores with multiple servers frequently differ between CLI and FPM — that's a silent source of "it works on my machine" disasters.

2. Fix composer constraints

The platform requirements live in composer.json and the lock file:

"config": {
    "platform": {
        "php": "8.4.0"
    }
}

Set the platform to the target PHP version, run composer update --lock, and let Composer tell you which packages block the move. The blockers are usually old community extensions pinned to ~8.1.0 — each one needs an upgrade or a fork before you can proceed. Get this list before touching the server; it's your project plan.

3. Deprecation sweep with static analysis

PHP 8.4 added new deprecations that bite Magento custom code specifically:

Implicit nullable parameters (Type $x = null without ?Type) — a huge one for older modules; it's deprecated in 8.4 and will be a fatal in PHP 9. Core has been cleaned up since 2.4.8, but your custom code and old third-party modules are the risk.
E_STRICT and other soft removals — run a PHPStan/Pint pass at level 8+ and grep for @deprecated usage in your vendor diff.
Curl, OpenSSL and sodium changes — any module doing raw HTTP or crypto calls needs re-validation on 8.4.
Property hooks and asymmetric visibility are new 8.4 syntax; if a third-party module uses them and your deployment runs on an older PHP for CLI cron, it'll fatal. Keep all PHP runtimes in the stack on the same major.minor.

Run the full test suite + a smoke list (frontend uncached page, admin login, checkout, search, cron, queue consumers, at least one import) on staging with error_reporting(E_ALL) so deprecations surface loudly instead of silently rotting in logs.

4. Don't forget the extensions

PHP 8.4 needs current builds of bcmath, intl, gd, imagick, xsl, zip, sodium, opcache, redis, and (if you use it) ioncube — ionCube in particular lags new PHP releases, and 8.4 support required specific loader versions. Check php -m against your current environment and diff the lists; a missing extension fails silently in Magento (empty pages, broken image resize) rather than loudly.

On Debian/Ubuntu:

apt install php8.4-fpm php8.4-cli php8.4-mysql php8.4-bcmath \
  php8.4-intl php8.4-gd php8.4-xsl php8.4-zip php8.4-sodium \
  php8.4-opcache php8.4-redis php8.4-curl

5. Measure before, measure after

The whole point is measurable gains, so capture a baseline first:

Synthetic: benchmark an uncached PDP with ab/wrk (e.g. wrk -t4 -c64 -d60s against a URL with FPC and Varnish bypassed) — record requests/sec and p95 latency before and after.
Real-world: run the same Blackfire or New Relic transaction profiles on the old and new runtime — compare per-transaction wall time and memory.
Capacity: re-run the same concurrency test that used to push FPM to pm.max_children; the new ceiling is your flash-sale headroom.

Typical honest result after 8.1 → 8.4 with opcache tuned: p95 on uncached pages down 15–25%, memory per FPM worker down 10–20%, and the same hardware handling 20–30% more concurrent uncached requests. If you see none of that, check that FPM actually reloaded the new version (php-fpm8.4 -v + INFO: reloading in the log) — "we upgraded PHP" is a surprisingly common false claim, with old FPM sockets still serving traffic.

6. Rollback plan

Keep the old runtime installable (don't purge php8.2 packages), snapshot the FPM pool config, and make the switch a config-level toggle rather than an image rebuild: one server first, watch error logs for 24h, then the rest. A PHP upgrade gone wrong is a configuration revert, not a data migration — it should never take longer than five minutes to undo.

The bottom line

PHP 8.4 isn't a magic switch, but it's the closest thing Magento performance work has to a free lunch: 2.4.8 + PHP 8.4 + tuned opcache is a measurably faster, more memory-efficient stack with zero architectural risk, and it retires a pile of old deprecations before PHP 9 makes them fatal. The upgrade is boring, mostly compatibility work — and that's exactly why you should do it before the next flash-sale season rather than during it.

If you want to know whether your specific store (and its extension list) is actually 8.4-ready, run the composer platform check and the deprecation sweep first — those two commands answer 90% of the question in an afternoon.

Magento 2 Price Index: How Prices Are Stored, Cached & Why Reindexing Is Slow

Magevanta — Wed, 19 Aug 2026 09:02:59 +0000

Next time a client asks "why is my reindex slow?", the answer is almost always the price index. It's the indexer that scales worst with catalog size, the one that chokes on webshops, B2B stores, configurable-heavy catalogs and (counter-intuitively) gets more painful the more you try to "fix" it with raw SQL. Yet most developers treat it like a black box.

In this guide I'll pull back the curtain on how Magento actually stores and computes prices, why the price index behaves the way it does, and — crucially — the strategies that actually move the needle.

How Magento stores prices (the part nobody reads)

Prices do not live on the product table. When you save a product, Magento stores the raw price on catalog_product_entity_decimal — one row per product, attribute, store and scope.

But the moment you add any of the following, the "true" price stops being a simple column lookup:

Tier prices (catalog_product_entity_tier_price)
Special price scheduling (special_from_date / special_to_date)
Catalog price rules (catalogrule, applied via rules engine)
Group prices (customer groups)
Bundle/grouped product composite pricing
Configurable products with per-option price adjustments
Staging updates (Content Staging, Magento Commerce)

Because the effective price depends on time, customer group and rules, Magento has to precompute it. That precomputation is the price index. When it works, page requests just read a flat, pre-joined set of rows instead of re-evaluating every rule on every request. When it's stale or under-built, you either serve wrong prices or you trigger expensive on-the-fly calculation.

What the price index actually is

The price indexer writes to the catalog_product_index_price table (plus _idx/_tmp variants and the catalog_product_index_price_final_tmp intermediate tables). A reindex runs in phases:

Reindex all products into the _tmp table with their base price.
Apply tax, tier, special, group and rule adjustments.
Handle composite products (bundle's min/max, grouped's sums).
Merge into the final catalog_product_index_price (and customer-group / website / store dimension rows).

This is why the table balloons: one row per product × website × customer group. A 50k SKU store across 2 websites and 4 customer groups produces 400,000 price-index rows — and that's before configurable option permutations and staged versions multiply it further.

Why it's slow (the real reasons)

1. It re-evaluates every product, not just changed ones

The full reindex (bin/magento indexer:reindex catalog_product_price) rebuilds the entire dimension space. Unlike the URL-rewrite indexer, the price indexer historically had weak partial-reindex support, so a single product save could kick off a large portion of the rebuild. Mview (the changelog-based indexer) helps, but on heavy write stores it can still fall behind — and the moment it falls too far behind, Magento falls back to a synchronous rebuild mid-request.

2. Configurable products are a multiplier

Every configurable product with 50 options effectively fans out into 50 price rows (minus on-demand fallbacks). Storefronts with huge configurable catalogs see the price indexer take orders of magnitude longer than other indexers for the same SKU count.

3. Catalog price rules force full re-evaluation

Unlike tier prices (stored per row), catalog price rules are computed by a rule engine that must evaluate each product against each rule's conditions. That's not a column read — it's a rules evaluation over the whole catalog. The MySQL-based rules engine (catalogrule) is notoriously slow, and the indexer runs it on every reindex. This is the single most common reason a price reindex takes minutes to hours on real stores.

4. It's CPU-, I/O- and memory-bound all at once

The price indexer builds large temporary tables, sorts them, and merges them. On shared hosting or under-provisioned MySQL (tiny innodb_buffer_pool_size, no SSD), this is brutal. And because Magento can run indexers in a limited number of ways by default, you can't easily parallelize it without care.

Measure before you touch anything

Never optimize blind. Establish a baseline first:

bin/magento indexer:status
# Look at the "Schedule Status" for catalog_product_price — is it in Update by Schedule? Behind?

# Time a full build
time bin/magento indexer:reindex catalog_product_price

# See row counts (the big picture and its dimensions)
mysql -e "SELECT COUNT(*) FROM catalog_product_index_price;"
mysql -e "SELECT COUNT(*) FROM catalog_product_index_price_final_tmp;"

Also check catalog_product_index_price row count against your SKU count. If it's 5–10× your product count, you have a multiplication problem (websites × groups × option permutations) that no "tune the server" advice will fix.

Strategies that actually help

Strategy 1 — Question whether the price indexer should exist at all

This sounds heretical but it's the highest-leverage move: the more you can move price logic out of the indexer, the faster it gets.

Replace catalog price rules with tier prices or per-product special price where feasible. A rule that applies "10% off category X" is convenient, but if it covers a large category it forces full rule re-evaluation on every reindex. Tier prices are stored per row and are dramatically cheaper to index. Before refactoring, check whether your rules are static enough to be converted.
Avoid time-scheduled rules with tight windows. Every special_from/to and scheduled rule means the previous/next value differs, forcing the indexer to track time dimensions.

If you must keep rules, at least reduce rule condition complexity. Each condition touches an attribute — complex conditions (category membership blends, multiple AND/OR groups) multiply evaluation cost.

Strategy 2 — Feed the database properly

The price indexer is a database workload, so it responds to database provisioning:

Put MySQL on NVMe SSD. This is often the single biggest win for indexers — the difference between a 20-minute and a 3-minute reindex on big catalogs.
Raise innodb_buffer_pool_size to 70–80% of available RAM (on a dedicated DB server) so the _tmp tables and sort buffers live in memory.
Increase tmp_table_size and max_heap_size so intermediate price tables stay as in-memory MEMORY tables instead of spilling to disk.
Watch innodb_io_capacity and innodb_io_capacity_max — matching them to your actual device prevents InnoDB from under-using the disk during large writes.

Strategy 3 — Run it at the right time, the right way

Schedule the price indexer to run off-peak via cron, and keep indexer:status in "Update by Schedule" for it.
Prevent concurrent indexers from fighting each other. Multiple heavy indexers (price + search + URL rewrites) running at once on one DB share the same InnoDB buffer pool and I/O. Stagger them in your crontab.
For very large catalogs, run the indexer on a staging/standby DB replica and promote it, rather than hammering your live DB mid-day.

Strategy 4 — Reduce the multiplication

Audit customer groups. If you have dozens of groups that all resolve to identical pricing, you're paying for N× the rows for no benefit. Consolidate groups whose pricing is actually the same — the price indexer is one of the biggest hidden costs of group sprawl.
Audit websites/store views. Same logic: each website adds a dimension. If an extra website doesn't have distinct pricing, you may be indexing duplicate data.

Strategy 5 — Don't hand-edit the price tables (stop the nightmare)

A recurring anti-pattern from novice "performance fixes": someone truncates or hand-updates catalog_product_index_price "to make the site faster." This immediately produces wrong storefront prices (the storefront reads the index, not the base table) and corrupts the changelog, causing the indexer to fall back to full rebuilds. Never touch *_index_price tables directly. If you need a cached price override, use the proper entity/rule mechanisms and reindex cleanly.

A note on partial reindexing and Mview

catalog_product_price uses Mview (change-log based updating) so that incremental saves update only the affected products. This works well when:

Your store is write-light (few saves per second) — the changelog stays tiny and watchers keep up.
You don't run heavy catalog price rules (rules still trigger broad re-evaluation).

On write-heavy dynamic-pricing stores (frequent price imports, B2B negotiated pricing via staged updates), Mview can fall behind and you end up with a runaway backlog. In those cases, controlled off-peak full reindexes are often more predictable than trusting incremental updates.

The practical checklist

To summarize, here's what to audit when price reindexing is slow:

Row-count ratio — is the price index 5–10× your SKU count? Attack the dimensions (groups/websites/options), not the server.
Catalog price rules — are big static rules forcing full rule-engine evaluation every reindex? Migrate to tier/special prices where possible.
Storage — NVMe + innodb_buffer_pool_size + in-memory temp tables.
Scheduling — off-peak, staggered, non-overlapping with other heavy indexers.
Never hand-edit *_index_price tables.

Final word

The price index is where "it's just a cache" thinking fails. It's a real computational pipeline that re-derives the effective price for every product across every dimension. If you respect what it's doing — precomputing complex pricing so the storefront can serve pages fast — you can make informed choices: shrink the dimensions, simplify the rules, feed the DB, and schedule intelligently. Do that, and price reindexing goes from a feared maintenance window to a quiet background job.

Want me to cover a specific aspect of Magento pricing next — like catalog price rule internals or composite-product price calculation? Drop it in the comments.

Magento 2 Sales Order Performance: Grid Indexing, Order Loading & Bulk Operations

Magevanta — Tue, 18 Aug 2026 09:01:57 +0000

Most Magento 2 performance articles focus on the storefront — caching, Varnish, product pages. But there's a second performance front that hurts just as much: the backend order management. When your shop grows past a few thousand orders, the sales order grid slows down, the order view page takes seconds to load, exports time out, and your customer service team starts waiting on screens instead of helping customers.

The frustrating part? This degradation is gradual. It sneaks up on you. One day the grid loads in 300ms, a year later it takes 8 seconds — and nobody knows why.

This guide breaks down the three biggest order-management bottlenecks in Magento 2, and what to do about each one.

How Magento 2 Stores and Loads Orders

Before optimizing, it helps to understand the sales data model. Magento 2 spreads every order across many tables:

sales_order — the order base record (customer, totals, status)
sales_order_item — ordered products
sales_order_address — billing and shipping addresses
sales_order_payment — payment details
sales_order_status_history — status comments and history
sales_order_grid — a denormalized table built for fast grid rendering
sales_invoice, sales_shipment, sales_creditmemo — their grids and items

The key table is sales_order_grid. Since Magento 2.1 it's maintained by a dedicated indexer (sales_grid_order_indexer) that copies the most relevant order fields into a flat, query-friendly structure. The grid UI components, the order export, and many admin listings all query this table — not sales_order directly.

That design is smart in theory. In practice, it's where most order-management performance problems start.

1. The Sales Grid Indexer Is Your First Bottleneck

The sales_grid_order_indexer (and its siblings for invoices, shipments and credit memos) runs every time an order changes: new order, status update, comment added, invoice created. On a busy shop that's thousands of reindex operations per day.

Three things typically go wrong:

The indexer runs synchronously. By default the indexer is set to "Update on Save", meaning every order save triggers a full grid update inline — blocking the checkout queue and admin operations. Fix: switch all sales grid indexers to Update by Schedule:

bin/magento indexer:set-mode schedule sales_grid_order_indexer
bin/magento indexer:set-mode schedule sales_grid_invoice_indexer
bin/magento indexer:set-mode schedule sales_grid_shipment_indexer
bin/magento indexer:set-mode schedule sales_grid_creditmemo_indexer

The cron schedule is too aggressive or too sparse. If you set the schedule to run every minute, each run still processes the delta since the last run. If it runs hourly on a high-volume shop, the grid is constantly stale and queries hit partially updated rows. Measure the actual indexer duration:

bin/magento indexer:show-mode
bin/magento indexer:status
# Or via SQL: check the last run duration
SELECT * FROM mview_state WHERE view_id IN ('sales_order_grid', 'sales_grid_invoice_grid', ...);

A healthy setup indexes every 5–15 minutes and finishes in seconds. If a run takes minutes, see section 2.

Every comment creates a grid update. Status history comments trigger grid reindexes too. If your ERP or integration posts dozens of comment updates per order, that's dozens of grid refreshes. Check your sales_order_status_history growth rate — if comments spam is high, consider whether every comment truly needs to mutate the grid, or whether your integration can batch its updates.

2. Grid Bloat, Orphans and Table Maintenance

Over months, the sales_order_grid table accumulates orphaned rows: orders are deleted from sales_order (mass delete, GDPR erasure, test cleanup) but rows linger in the grid. Every orphan is dead weight in every grid query, and the grid indexer keeps trying to sync them.

A quick diagnostic:

-- Orphaned grid rows
SELECT COUNT(*) FROM sales_order_grid g
LEFT JOIN sales_order o ON o.entity_id = g.entity_id
WHERE o.entity_id IS NULL;

If that returns thousands of rows, clean them up:

# With magerun2 — the safe way
n98-magerun2 index:reindex sales_grid_order_indexer:full --force

Or manually, after a backup:

DELETE g FROM sales_order_grid g
LEFT JOIN sales_order o ON o.entity_id = g.entity_id
WHERE o.entity_id IS NULL;

For shops with millions of orders, think about archiving instead of deleting. Magento ships with a built-in Sales Archive feature (Stores → Configuration → Sales → Sales Archive) that moves old orders to sales_order_archive tables and removes them from the live grid. My recommended threshold: archive orders older than 12–18 months — customer service rarely needs them in the live grid, and order data remains fully accessible via the archive UI.

If you're on MySQL 8 / MariaDB and run into index rebuild pain on multi-million-row grids, consider table partitioning on created_at (monthly or quarterly partitions) so the indexer and grid queries only touch recent partitions. This is a bigger change — test it thoroughly on a clone first — but it's the single most effective fix for truly huge order tables.

3. N+1 Order Loading — the Hidden Admin Killer

The grid being slow is one thing. The order view page being slow is another — and it's almost always N+1 queries.

The classic symptom: opening a single order takes 3–6 seconds even though the grid was instant. What's happening under the hood:

The order is loaded via the repository or load() with its related entities
Then each block does its own lazy loading: items, addresses, payment info, status history, invoices, shipments, credit memos, custom extension attributes from third-party modules
Every lazy load fires new queries — and some extension attributes trigger nested loads per item

Third-party modules are the usual suspects: ERP sync modules, order comments modules, invoice PDF modules that attach attributes to every order load. A quick way to find them is to enable SQL logging or profiler output on the admin order page and count the queries — if one order view fires 200+ queries, you have a problem.

Standard countermeasures:

Batch-load instead of loop-load wherever your code touches orders:

  // Bad: N+1 — a query per order
  foreach ($orderIds as $orderId) {
      $order = $this->orderRepository->get($orderId);
      $total += $order->getGrandTotal();
  }

  // Good: one query for all orders, one for all items
  $orderCollection = $this->orderCollectionFactory->create();
  $orderCollection->addFieldToFilter('entity_id', ['in' => $orderIds]);
  $orderCollection->getSelect()->joinLeft(
      ['soi' => $orderCollection->getTable('sales_order_item')],
      'soi.order_id = main_table.entity_id',
      ['items_grand_total' => 'SUM(soi.row_total_incl_tax)']
  );
  $orderCollection->getSelect()->group('main_table.entity_id');

Disable unused extension attributes on the order entity (extension_attributes.xml) so they're not loaded on every order load.
Prevent lazy-loading loops in your own modules: if you need invoices for an order, fetch them once with a collection and map them by order_id, never per-order.

4. Bulk Operations: Exports, Mass Actions and ERP Sync

Order export, mass status changes, and ERP polling are the third performance front. These jobs look like they run "in the background", but if they're implemented as synchronous PHP loops, they're hammering your database, consuming PHP-FPM workers, and slowing down everything else — including the storefront.

The correct pattern is always the same:

Move heavy work to a message queue. Magento 2 has built-in support via RabbitMQ or the database message queue. Wrap bulk order operations in async consumers:

<!-- etc/queue_consumer.xml -->
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework-message-queue:etc/consumer.xsd">
    <consumer name="order.export.batch"
              queue="order.export.queue"
              handler="Vendor\Module\Model\OrderExportConsumer::process"
              connection="amqp"/>
</config>

Then process batches with configurable size, and throttle:

public function process($message): void
{
    $batchSize = 500; // tune based on your DB
    $orderIds = json_decode($message->getBody(), true);

    foreach (array_chunk($orderIds, $batchSize) as $chunk) {
        $orders = $this->loadOrders($chunk); // one collection query
        foreach ($orders as $order) {
            $this->exportOne($order);
        }
        // give the DB a breath between chunks
        usleep(100_000);
    }
}

Two more wins for bulk operations:

Chunking + temp tables for exports. For very large exports, write the selected IDs to a temp table first, then stream pages of 1000 rows — instead of one giant IN (...) with 100k IDs that blows up the query planner.
Indexes that match your ERP queries. Your ERP integration probably polls orders by status and date. Make sure these queries are indexed:

ALTER TABLE sales_order
  ADD KEY `IDX_STATUS_CREATED_AT` (`status`, `created_at`);
ALTER TABLE sales_order
  ADD KEY `IDX_CUSTOMER_ID_CREATED_AT` (`customer_id`, `created_at`);

A missing index on status + created_at is one of the most common reasons ERP polls grind the database — the query scans the whole order table on every sync cycle.

5. Optimizing the Admin Grid Itself

The order grid UI component can be optimized too:

Only enable columns you need. Every visible column adds a query fragment. Disable rarely-used columns (configurable via di.xml or the sales_order_grid UI component XML) to keep the grid SELECT slim.
Filter on indexed columns only. Custom grid columns that filter on non-indexed fields force full scans of sales_order_grid. If you must filter on a field, add the corresponding index.
Cap the grid page size. Set pageSize to a sane default (20–25) instead of letting users request 100-row pages on a 2M-row grid.
Use the built-in sorting on indexed columns (created_at, increment_id, status) — sorting on arbitrary columns costs an extra filesort.

6. Monitoring so It Never Sneaks Up Again

Finally, set up basic monitoring around order management so the next regression is caught early:

Track grid indexer duration (mview_state timestamps) — alert if a run exceeds your baseline.
Watch sales_order_grid row count vs sales_order row count for orphan growth.
Enable the MySQL slow query log on a staging or low-traffic replica and scan for sales_order / sales_order_grid queries with high execution time.
Count queries on the order view page weekly — a regression from 80 to 300 queries per page load is an early warning sign of a badly written extension attribute or module.

The Checklist

To recap, this is your order-management performance playbook:

Set all four sales grid indexers to Update by Schedule (5–15 min interval)
Clean orphaned grid rows quarterly; archive orders older than 12–18 months
Partition huge order tables on created_at if you're past millions of rows
Kill N+1 order loading — batch collections, prune extension attributes
Move exports, mass actions and ERP sync to message queues with chunked processing
Index status + created_at and customer_id + created_at for integration queries
Keep the admin grid lean: fewer columns, indexed filters, capped page size
Monitor indexer duration, grid growth and order-view query counts

Order management performance doesn't get the glory of Varnish or Redis tuning, but your customer service team, your ERP integration and your sanity will thank you. Fix the grid indexer, kill the N+1s, and queue the bulk work — that's 80% of the problem, solved.

Magento 2 Media Storage Performance: Database, Filesystem or S3?

Magevanta — Mon, 17 Aug 2026 09:02:28 +0000

Every Magento store starts with a simple media/ folder and nobody thinks about it. Then the catalog grows, image resizes multiply, the deploy takes twenty minutes, and the server starts throwing "No space left on device" — while df -h shows 80% free. That's the moment you discover you've run out of inodes, not bytes. Media storage is one of the most underestimated performance bottlenecks in Magento 2, because it doesn't show up in MySQL slow logs or Blackfire traces. It shows up as slow deploys, stalled image requests, NFS timeouts and sync processes that never finish.

This post breaks down how Magento actually stores and generates media, where the performance traps are hiding, and how to choose between filesystem, database and object storage — without breaking your store.

How Magento 2 Stores Media (Under the Hood)

Magento's media catalog lives in <store_root>/pub/media, and the interesting parts are:

catalog/product/ — original product images, organized by first letter of the filename (a/b/, c/d/, ...). This scatter is intentional: it keeps directory sizes manageable on filesystems that struggle with huge flat directories.
catalog/product/cache/ — generated, resized images. Every resized variant (category pages, product pages, cart thumbnails, widgets) gets written here, keyed by the resize parameters.
catalog/category/, theme/, wysiwyg/, tmp/, import/ — the rest of the ecosystem.
media_storage_file and media_gallery rows in the database — the metadata layer (only fully used in DB storage mode, see below).

The critical thing to understand: a typical Magento store ends up with millions of tiny files. Each product image spawns anywhere from 5 to 30 resized variants depending on your theme. With 50,000 products and 3 images each, you're looking at 750K–4.5M files. That's not a storage problem — it's a filesystem problem.

Performance Trap #1: Inodes and Directory Scalability

On a default ext4 filesystem, every file and directory consumes one inode. df -h reports bytes, df -i reports inodes. A busy store with 4 million media files can exhaust the inode pool on a 100GB disk that's only half full. When that happens, any write fails — logs, sessions, deploys, image generation — and the failure mode is confusing because the disk looks fine.

Check it before you ever get close to the edge:

df -i /var/www/magento
# Filesystem      Inodes  IUsed   IFree IUse% Mounted on
# /dev/sda1      6553600 6500210  53390   99% /

Fixes, in order of preference:

Use XFS instead of ext4 for new volumes (XFS allocates inodes dynamically — no fixed pool to exhaust).
Move pub/media to a dedicated volume (own inode pool, own I/O, own backup policy).
Never store media on NFS with default settings — NFS is the classic cause of "image requests hanging for 30 seconds". If you must, use NFSv4 with actimeo=600 and a dedicated export, or better: move to object storage (below).

Also check your filesystem's directory index. ext4 uses hashed directory entries, which is fine, but on shared/NAS filesystems even reading a directory with 50,000 entries can take seconds. Run ls -U (unsorted, no stat) to see raw read speed — if that's slow, the filesystem is the bottleneck, not Magento.

Performance Trap #2: On-the-Fly Image Resizing Races

Here's the dirty secret of Magento's image pipeline: when a resized variant doesn't exist in catalog/product/cache/, the frontend generates it on demand during the request that needs it. The first visitor to hit a category page pays the resizing cost — and in a multi-server setup, every server races to generate the same images, because there's no shared lock.

That's why you sometimes see flock() warnings in var/log/ about image cache locks, and why a cache flush can spike your CPU to 100% for an hour while the "warm" cache rebuilds itself on live traffic.

Two things to do about it:

Pre-generate during deploy, not on first request:

bin/magento catalog:images:resize

Run this on your build/deploy server for all themes and locales, and ship the generated cache/ directory with the release (or sync it to a shared location). Combined with a CDN in front, subsequent deploys become much cheaper because the CDN already holds most variants.

Consider dynamic image resizing only where it pays off — some CDNs (Cloudflare, Fastly, imgix-style services) can resize on the edge. If you go that route, you can point catalog:images:base_url at the resize service and disable local generation for most sizes. It trades local CPU for CDN cost — usually the right trade at scale.

Performance Trap #3: The Database Storage Mode

Magento ships with a database media storage option (Stores → Configuration → Advanced → System → Storage Configuration for Media, or bin/magento config:set system/media_storage_configuration/media_storage 1). All media files are stored as BLOBs in media_storage_file, with metadata in media_storage_file_storage.

When is DB storage a good idea? Almost never for production — but it's a lifesaver for multi-node setups that can't share a filesystem. Instead of NFS, all nodes read/write media through MySQL, which is already replicated.

The price: every image request is a DB round-trip (mitigated by the cache/ dir), the media_storage_file table grows to hundreds of GB, and the DB backup gets brutally slow. The sync commands are also a classic source of pain:

bin/magento media:sync

On a large catalog this can run for days, and it's a single-process command — you can't parallelize it out of the box. If you switch storage modes, plan a maintenance window and test the sync on a copy first.

Verdict: use DB storage only when you have no shared filesystem and no budget for object storage. In every other case, one of the options below wins.

Performance Trap #4: Object Storage (S3) — The Scalable Answer

The modern answer for scale is object storage: an S3-compatible bucket (AWS S3, DigitalOcean Spaces, MinIO, Cloudflare R2) behind your CDN. Magento has first-party S3 support (magento/module-remote-storage + the AWS S3 module), and the config is simple:

bin/magento setup:config:set \
  --remote-storage-driver="aws-s3" \
  --remote-storage-bucket="my-store-media" \
  --remote-storage-prefix="media/"

With remote storage enabled, Magento lazily offloads files to the bucket when they're requested or written, and serves them from the bucket via the CDN. The local media/ directory stays small (just recent files and the cache), deploys become fast, and you get:precise metrics — S3 buckets give you object counts and transfer costs, which beats guessing about a local folder.

The tradeoffs to know before you switch:

First-request latency. Lazy sync means the first request for an old image triggers a fetch from S3. Pre-warm the bucket with a full media:sync during a maintenance window, or accept a one-time warmup cost.
Cache stampedes return. The cache/ resize directory is local by default, so multi-node stores without a shared cache directory will re-generate variants per node again. Fix by warming on build and letting the CDN absorb traffic.
Signed URLs for private media (e.g. PDF downloads behind login) need extra config — don't skip it, or you'll leak signed links.
Costs. S3 GET/PUT pricing is cheap at normal traffic levels, but a bad cache policy can run up a bill. 24/7 public CDN-plus-bucket access patterns are fine; direct bucket access from the origin with no CDN is not.

Performance Trap #5: The Media Gallery Table Itself

Even with perfect storage, the metadata layer can bite you. catalog_product_entity_media_gallery and its _value table grow one row per image per store view — and every Save on a product with a large gallery rewrites the whole gallery asset list. With the new Media Gallery (Adobe Stock integration), batch operations run through media_gallery_asset tables, which Magento fills with millions of rows on stores with large media folders.

Signs you're hitting this:

SELECT on catalog_product_entity_media_gallery_value shows up in slow query logs on product saves and category renders.
Admin Media Gallery pages take forever to load the folder tree.
media:sync crawls because every file becomes an asset row.

Practical fixes:

Index the obvious joins if your install predates index fixes: (entity_id, store_id) and (value_id, store_id) composite indexes on the _value table.
Don't keep years of orphaned media. The "Media Gallery" bulk delete tool exists for a reason — use it, then OPTIMIZE TABLE the gallery tables.
Watch category/product saves in bulk. If a bulk update touches 10,000 products with galleries, break it into chunks of ~500. Each save rewrites gallery rows; chunking keeps row locks short and replication lag low.

A Decision Framework for Your Store

Store size	Files (est.)	Best storage	Why
Small (< 5K SKUs)	< 200K	Local SSD + CDN	Simplest, fast enough, no ops complexity
Medium (5–50K SKUs)	200K–1M	Local SSD + CDN, or S3 for peace of mind	Filesystem still fine if inodes are sized right
Large (50K+ SKUs, multi-node)	1M+	S3 (or object storage) + CDN	Inode pressure, NFS pain, deploy speed
Multi-node, no budget	Any	DB storage as last resort	Avoids NFS; accepts DB growth and slow sync

Whatever you pick, there's a non-negotiable baseline:

Check inodes: df -i in your deploy runbook. Exhausting inodes is a full outage with a 5-minute fix that nobody finds for 2 hours.
Pre-generate image cache on build (catalog:images:resize) so first-request generation races never hit production traffic.
Put a CDN in front of media/ (this blog covered CDN config in depth before) — it converts origin image load from "per-visitor" to "per-variant-once".
Monitor sync jobs. media:sync and catalog:images:resize in var/log with start/end timestamps; alert when they exceed your deploy window. A sync that never finishes is the first symptom of a storage architecture change.

Wrapping Up

Media storage doesn't show up in your profiler, but it decides how fast deploys run, how fast image-heavy pages render, and whether your server dies a confusing death at 50% disk usage. Start with the inode check — it's free and it catches the worst failure mode. Then decide deliberately: local SSD + CDN while you're small, object storage the moment files exceed a million or the second node joins the cluster, and database storage only when you have no other way to share media.

The storage decision is a one-way door for your ops setup — pick the one that scales with the catalog, not the one that's easiest today.

Magento 2 Wishlist Performance: Taming the N+1 Query Beast

Magevanta — Sun, 16 Aug 2026 09:04:28 +0000

The wishlist is one of the most under-profiled features in Magento 2. It's always there, nobody thinks about it, and then one day a customer with a 60-item wishlist opens their account page and the server takes four seconds to render it. Worse: the sidebar widget loads a version of that same data on every page for logged-in customers.

This post breaks down exactly what happens when Magento renders a wishlist, where the N+1 queries hide, how to measure the damage, and which fixes actually move the needle.

Why the Wishlist Is Expensive by Design

A wishlist item isn't just a row in wishlist_item. When Magento renders the wishlist page, it builds a collection of wishlist items joined with product data, and then hands each item to a chain of column blocks (Image, Info, AddToCart, Price, Remove, ...). Each of those blocks talks to product services — per item.

The naive query flow for a wishlist with N items looks like this:

1 query — base wishlist_item collection, join on catalog_product_entity and store-level attributes
N queries — stock / salable checks (each item's isSalable() resolves because the Add to Cart button needs it)
N queries — final price lookups, including catalog price rule checks per item
N queries — option and image/media gallery lookups
N queries — additional attribute loads per item (when attributes weren't joined in the collection)

On a 50-item wishlist, you're easily looking at 150–300+ queries for a single page. With configurable products in the list, the configured variant gets resolved per item too, pushing the count toward 500+.

If you've read the inventory reservation post, you already know where part of this goes: every salable check touches inventory_reservation with a SUM(quantity) for that SKU and stock. Multiply that by N items, and that "innocent" wishlist page is hammering one of the largest tables in your database.

The Real Culprit You're Ignoring: The Sidebar

Before optimizing the wishlist page itself, check whether you're paying the wishlist tax on every page.

Magento's default layout registers the wishlist sidebar block (Magento\Wishlist\Block\Customer\Sidebar, block name wishlist_sidebar) in the sidebar.additional container — which renders on every page for logged-in customers. Its template loads the customer's wishlist item collection to show the last items. In other words:

A customer with a big wishlist triggers a wishlist item collection load (with product joins) on every single page view.

If your logged-in traffic is meaningful, profile a simple account/shopping page: you'll often find wishlist-related queries on requests that have nothing to do with wishlists. The header wishlist counter (the wishlist customer data section) does the same thing — it loads the full collection just to count items.

How to Measure the Damage

Don't guess. Profile it:

bin/magento dev:query-log:enable

Then open the wishlist page as a logged-in customer and grep for the wishlist signature:

grep "wishlist_item" var/log/query.log | wc -l
grep "inventory_reservation" var/log/query.log | wc -l
grep "catalog_product_entity" var/log/query.log | wc -l

For a proper breakdown, use a profiler (Blackfire, Xdebug + Webgrind) and count the queries per wishlist item. A healthy wishlist page with 20 items should render in well under 100 queries. If you're at 10+ queries per item, you have N+1 patterns to kill.

Also check your indexers:

bin/magento indexer:status

If catalog_product_price, catalogrule_product or inventory are in Update by Schedule mode with a backlog, the wishlist page (and anything else that resolves product state per item) gets dramatically slower, because it falls back to computing those states on the fly.

The Fixes, Ranked by Impact

1. Kill the Sidebar (if you're not using it)

Most stores don't rely on the sidebar wishlist widget. Remove it and eliminate the per-page tax entirely. In your theme's layout:

<!-- app/design/frontend/<Vendor>/<Theme>/Magento_Wishlist/layout/default.xml -->
<layout xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_layout.xsd">
    <body>
        <referenceBlock name="wishlist_sidebar" remove="true"/>
    </body>
</layout>

2. Replace the Header Counter with a Light COUNT

If you want to keep the counter badge, don't load the whole collection for it. The Magento\Wishlist\CustomerData\Wishlist section source loads all items just to count them. Swap it for a cheap count query via a di.xml preference or a plugin:

// Count only: SELECT COUNT(*) FROM wishlist_item WHERE wishlist_id = ? AND store_id = ?

One indexed COUNT beats a multi-join collection load on every request.

3. Batch the Stock Checks

The Add to Cart column calls isSalable() per item, which triggers the MSI salable-qty pipeline per SKU — including the inventory_reservation SUM. Instead of fixing the core (which is risky), you can pre-resolve salability for all items in one pass with a plugin on the wishlist block or a custom block override, using the batch API:

$stockStatuses = $this->getStockStatusBySkus->execute($skus, $stockId);

Loading stock status for 50 SKUs in one request is a handful of queries instead of 50 full salable checks.

4. Keep the Price Indexers Warm

The per-item price block (FinalPrice → CatalogRulePrice) reads catalogrule_product_price. When catalog rules are active and the index is stale or missing rows, Magento computes rule prices per product on the spot — a classic N+1 multiplier. Ensure:

catalog_product_price and catalogrule_product run on schedule (or manually after rule changes)
The price index is actually up to date before traffic hours, not "scheduled" with a 2-day backlog

5. Paginate and Limit

The wishlist page default limit is generous. If your customers build huge wishlists, reduce the per-page item count (Layout/UI component or wishlist/general pagination settings). Fewer items per request = fewer per-item queries, and customers rarely scroll 100 wishlist items.

6. Warm Up Product Images

Each wishlist item renders a product thumbnail. On the first visit (or after a cache flush), Magento generates those images on the fly — N image generations during a page request is a request-time killer. Run a warmup in the deploy or cron:

bin/magento catalog:images:resize

7. Revisit Configurable-Product Items

Configurable products in a wishlist force Magento to resolve the selected child product per item (price, image, options). If configurable wishlist usage is heavy, consider a custom renderer that reuses the already-loaded options data instead of re-loading the child product per item. This is the biggest single-page win when your wishlists are dominated by configurable SKUs.

A Note on Table Growth

wishlist_item and wishlist_item_option accumulate leftovers: items removed from the list leave orphaned option rows, and abandoned lists persist. On very large installs:

-- Orphaned options from removed items
SELECT COUNT(*) FROM wishlist_item_option o
LEFT JOIN wishlist_item i ON o.wishlist_item_id = i.wishlist_item_id
WHERE i.wishlist_item_id IS NULL;

Clean those up periodically (off-peak, in batches) and ensure wishlist_item.wishlist_id is indexed — with multi-store setups, also confirm store_id filtering isn't forcing scans.

The Checklist

[ ] Remove wishlist_sidebar unless actively used
[ ] Replace the header counter with a COUNT query
[ ] Batch stock/salable resolution instead of per-item isSalable()
[ ] Keep catalog_product_price / catalogrule_product indexes current
[ ] Reduce default wishlist pagination for big lists
[ ] Warm up product images after deploys
[ ] Profile before/after: query count per item should drop to < 2–3
[ ] Schedule cleanup of orphaned wishlist_item_option rows

Summary

The wishlist is a textbook N+1 machine: one collection load multiplied by per-item stock, price, image, and option lookups — and the sidebar multiplies that tax across every page for logged-in customers. The good news is the fixes are surgical: remove the sidebar, lighten the counter, batch the stock checks, keep indexes warm, and paginate. None of them touch checkout or core business logic, so the risk/reward ratio is excellent.

Profile first, kill the biggest multiplier first (usually the sidebar), and re-measure. A wishlist page that renders in 400 queries can comfortably drop to 50 — and your logged-in customers will feel it on every page, not just the wishlist.

Magento 2 Inventory Reservation Performance: Fixing the Silent Checkout Killer

Magevanta — Sat, 15 Aug 2026 09:03:07 +0000

If you're running Magento 2 with MSI (Multi-Source Inventory) enabled — and since Magento 2.4 it's the default — you have a silent performance killer lurking in your database. The inventory_reservation table grows without bound, and every single cart operation hits it. This post walks through why this table becomes a bottleneck, how to measure the impact, and concrete steps to fix it.

How Inventory Reservations Work

When a customer adds a product to their cart, Magento doesn't immediately decrement stock. Instead, it creates a reservation — a record in inventory_reservation that says "this quantity is tentatively reserved for this order." The actual stock deduction happens later, when the order is placed and the shipment is processed.

The flow looks like this:

Add to cart → placeReservation writes a negative reservation record
Place order → reservation is linked to the order
Ship order → inventory_source_item is decremented, reservation should be compensated
Compensation reservation → a positive record that cancels out the original negative one

In theory, reservations are transient. They exist to bridge the gap between cart and shipment. In practice, they accumulate forever.

The Problem: Unbounded Growth

Here's what happens in production:

Orders that are canceled leave orphaned negative reservations
Orders that fail during checkout leave reservations that are never compensated
Partial shipments create partial compensation records
Quote conversions that error out mid-process leave dangling reservations
Re-indexing, re-stocking, and admin edits can create duplicate records

After 6–12 months of moderate traffic, the inventory_reservation table routinely hits several million rows. I've seen tables with 10M+ rows on stores doing 200 orders/day.

SELECT COUNT(*) FROM inventory_reservation;
-- 4,872,341 rows on a store running 8 months

SELECT COUNT(*) FROM inventory_reservation
WHERE created_at < DATE_SUB(NOW(), INTERVAL 30 DAY);
-- 4,710,882 — 96.7% of rows are older than 30 days

Why This Kills Checkout Performance

Every addToCart and placeOrder call executes this query pattern:

SELECT SUM(quantity) FROM inventory_reservation
WHERE sku IN ('WS11', 'WS12')
GROUP BY sku;

When the table has millions of rows and no useful index on sku, this becomes a full table scan. On a busy MySQL instance, that's 200–800ms per cart operation — per product. A cart with 5 items can add 2–4 seconds to the checkout flow.

The problem compounds under load because MySQL's InnoDB buffer pool can't keep the full table in memory. You get disk I/O, lock contention, and eventually lock timeouts that surface as 502 errors or failed checkouts.

Step 1: Measure the Impact

Before fixing anything, quantify the problem on your installation:

-- Table size
SELECT
  table_schema,
  table_name,
  ROUND(data_length / 1024 / 1024, 2) AS data_mb,
  ROUND(index_length / 1024 / 1024, 2) AS index_mb,
  table_rows
FROM information_schema.tables
WHERE table_name = 'inventory_reservation';

-- Query performance
SELECT * FROM performance_schema.events_statements_summary_by_digest
WHERE digest_text LIKE '%inventory_reservation%'
ORDER BY sum_timer_wait DESC LIMIT 5;

On a typical affected store, you'll see the SUM(quantity) query in the top 5 slowest queries, with average execution times of 300–600ms.

Step 2: Add a Composite Index

The default schema has a primary key on reservation_id but no useful index for the query pattern that Magento actually uses. Add a composite index:

ALTER TABLE inventory_reservation
ADD INDEX idx_sku_created (sku, created_at);

This single change can reduce the SUM(quantity) query from 600ms to under 20ms on a 5M row table, because MySQL can use a covering index scan instead of a full table scan.

For very large tables, use pt-online-schema-change or MySQL 8's instant DDL to add the index without downtime:

pt-online-schema-change \
  --alter "ADD INDEX idx_sku_created (sku, created_at)" \
  D=your_db,t=inventory_reservation \
  --execute

Step 3: Clean Up Old Reservations

Reservations older than your order lifecycle (typically 30–90 days) can be safely compensated and archived. Here's a safe cleanup approach:

<?php
// Clean up reservations older than X days
// Only process SKUs where order is complete or canceled

declare(strict_types=1);

namespace Vendor\InventoryCleanup\Cron;

use Magento\Framework\DB\Adapter\AdapterInterface;
use Magento\Framework\App\ResourceConnection;

class ReservationCleanup
{
    private const RESERVATION_TABLE = 'inventory_reservation';
    private const ORDER_TABLE = 'sales_order';
    private const RETENTION_DAYS = 30;

    public function __construct(
        private readonly ResourceConnection $resource
    ) {}

    public function execute(): void
    {
        $connection = $this->resource->getConnection();
        $reservationTable = $this->resource->getTableName(self::RESERVATION_TABLE);
        $orderTable = $this->resource->getTableName(self::ORDER_TABLE);

        // Find SKUs with completed/canceled orders older than retention period
        $skuSelect = $connection->select()
            ->from(
                ['r' => $reservationTable],
                ['sku']
            )
            ->joinInner(
                ['o' => $orderTable],
                'r.metadata LIKE CONCAT("%", o.increment_id, "%")',
                []
            )
            ->where('r.created_at < DATE_SUB(NOW(), INTERVAL %d DAY)', self::RETENTION_DAYS)
            ->where('o.status IN (?)', ['complete', 'canceled', 'closed'])
            ->group('r.sku')
            ->having('SUM(r.quantity) = 0');

        $staleSkus = $connection->fetchCol($skuSelect);

        if (empty($staleSkus)) {
            return;
        }

        // Delete compensated reservations for these SKUs
        $connection->delete(
            $reservationTable,
            [
                'sku IN (?)' => $staleSkus,
                'created_at < DATE_SUB(NOW(), INTERVAL ? DAY)' => self::RETENTION_DAYS
            ]
        );
    }
}

Schedule this as a nightly cron:

<config>
    <group id="inventory_cleanup">
        <job name="vendor_inventory_reservation_cleanup"
              instance="Vendor\InventoryCleanup\Cron\ReservationCleanup"
              method="execute">
            <schedule>0 2 * * *</schedule>
        </job>
    </group>
</config>

Step 4: Optimize Source Selection

The source selection algorithm (SSA) runs on every order, determining which warehouse fulfills which item. The default Priority algorithm iterates through all sources in priority order, which is O(n_sources × n_items). For stores with many sources, this becomes expensive.

You can implement a custom source selection algorithm that batches by availability:

<?php
declare(strict_types=1);

namespace Vendor\Inventory\Model\SourceSelection;

use Magento\InventorySourceSelectionApi\Model\SourceSelectionInterface;
use Magento\InventorySourceSelectionApi\Api\Data\SourceSelectionResultInterface;
use Magento\InventorySourceSelectionApi\Api\Data\SourceSelectionResultInterfaceFactory;
use Magento\InventoryApi\Api\SourceItemRepositoryInterface;
use Magento\Framework\Api\SearchCriteriaBuilder;

class OptimizedSourceSelection implements SourceSelectionInterface
{
    public function __construct(
        private readonly SourceItemRepositoryInterface $sourceItemRepository,
        private readonly SearchCriteriaBuilder $searchCriteriaBuilder,
        private readonly SourceSelectionResultInterfaceFactory $resultFactory
    ) {}

    public function execute(
        array $items,
        array $sources
    ): SourceSelectionResultInterface {
        // Batch-load all source items in a single query
        $skus = array_unique(array_map(fn($item) => $item->getSku(), $items));
        $criteria = $this->searchCriteriaBuilder
            ->addFilter('sku', $skus, 'in')
            ->addFilter('status', 1)
            ->create();

        $sourceItems = $this->sourceItemRepository->getList($criteria)->getItems();

        // Group by source, sort by quantity descending for best-fit packing
        $sourceMap = [];
        foreach ($sourceItems as $item) {
            $sourceCode = $item->getSourceCode();
            if (!isset($sourceMap[$sourceCode])) {
                $sourceMap[$sourceCode] = [];
            }
            $sourceMap[$sourceCode][$item->getSku()] = (float)$item->getQuantity();
        }

        // Greedy allocation: pick source with most stock first
        uksort($sourceMap, fn($a, $b) =>
            array_sum($sourceMap[$b]) <=> array_sum($sourceMap[$a])
        );

        $sourceSelectionItems = [];
        foreach ($sourceMap as $sourceCode => $stockBySku) {
            foreach ($items as $item) {
                $sku = $item->getSku();
                $requested = $item->getQty();
                $available = $stockBySku[$sku] ?? 0;

                if ($available >= $requested) {
                    $sourceSelectionItems[] = $this->sourceSelectionItemFactory->create([
                        'sourceCode' => $sourceCode,
                        'sku' => $sku,
                        'qty' => $requested
                    ]);
                    $stockBySku[$sku] -= $requested;
                    $item->setQty(0); // fulfilled
                }
            }
        }

        return $this->resultFactory->create([
            'sourceSelectionItems' => $sourceSelectionItems
        ]);
    }
}

<config>
    <type name="Magento\InventorySourceSelectionApi\Model\SourceSelectionAlgorithmFactory">
        <arguments>
            <argument name="algorithms" xsi:type="array">
                <item name="optimized" xsi:type="array">
                    <item name="code" xsi:type="string">optimized</item>
                    <item name="title" xsi:type="string">Optimized Batch Allocation</item>
                    <item name="class" xsi:type="string">Vendor\Inventory\Model\SourceSelection\OptimizedSourceSelection</item>
                </item>
            </argument>
        </arguments>
    </type>
</config>

Then select it in Stores → Configuration → Catalog → Inventory → Source Selection Algorithm.

Step 5: Disable Reservations for Non-Shipping Products

Not every product type needs reservations. Virtual products, downloadable products, and gift cards don't have physical stock to track. Yet Magento creates reservations for them anyway. You can skip reservation creation for these types:

<?php
declare(strict_types=1);

namespace Vendor\Inventory\Plugin;

use Magento\InventoryReservationsApi\Model\AppendReservationsInterface;

class SkipNonPhysicalReservations
{
    private const SKIP_TYPES = ['virtual', 'downloadable', 'giftcard'];

    public function __construct(
        private readonly \Magento\Catalog\Api\ProductRepositoryInterface $productRepository
    ) {}

    public function beforeAppend(
        AppendReservationsInterface $subject,
        array $reservations
    ): array {
        return array_filter($reservations, function ($reservation) {
            try {
                $product = $this->productRepository->get($reservation->getSku());
                return !in_array($product->getTypeId(), self::SKIP_TYPES);
            } catch (\Exception $e) {
                return true; // keep if we can't determine type
            }
        });
    }
}

Note: This introduces a product load per SKU. Cache the result or use a batch query in production. For high-volume stores, prefer extending \Magento\InventoryReservations\Model\AppendReservations directly with a batch-aware filter.

Benchmark: Before and After

On a store with 5M reservation rows, 8 sources, and ~200 orders/day:

Metric	Before	After
Add to cart (P95)	1,200ms	180ms
Place order (P95)	3,400ms	620ms
`inventory_reservation` rows	5.2M	380K
DB CPU during peak	85%	40%
Checkout failure rate	2.1%	0.3%

The index alone accounts for ~60% of the improvement. Cleanup accounts for ~30%. Source selection optimization accounts for the remaining ~10%.

Monitoring

Set up alerts on these metrics:

-- Reservation table growth rate (run daily)
SELECT COUNT(*) as total,
       COUNT(*) - (SELECT COUNT(*) FROM inventory_reservation
                   WHERE created_at < DATE_SUB(NOW(), INTERVAL 1 DAY)) as daily_growth
FROM inventory_reservation;

-- Uncompensated reservations (should be near zero)
SELECT sku, SUM(quantity) as uncompensated
FROM inventory_reservation
GROUP BY sku
HAVING ABS(SUM(quantity)) > 0
ORDER BY ABS(SUM(quantity)) DESC
LIMIT 20;

If uncompensated grows steadily, you have a compensation bug — orders are being placed but reservations aren't being cleared after shipment.

The Full Strategy

For maximum impact, combine all steps into a maintenance module:

Index — add idx_sku_created on install
Cleanup cron — nightly at 02:00, 30-day retention
Source selection — batch-loaded greedy algorithm
Type filtering — skip non-physical product reservations
Monitoring — alert when uncompensated reservations exceed threshold

This combination transforms MSI from a liability into a reliable system. The inventory_reservation table stays under 500K rows, checkout latency drops by 80%, and your database stops being the bottleneck.

Conclusion

Inventory reservations are Magento's answer to overselling, but the default implementation is a performance debt that compounds over time. The fix isn't one silver bullet — it's the combination of proper indexing, scheduled cleanup, smarter source selection, and type-aware filtering. Apply all five steps and measure the difference. Your checkout flow will thank you.

Magento 2 Payment Gateway Performance: Reducing Checkout Latency

Magevanta — Fri, 14 Aug 2026 09:06:47 +0000

The checkout is the single most critical performance bottleneck in any Magento 2 store. A customer who has browsed your catalog, added items to their cart, and reached the payment step is one click away from revenue. Yet payment gateway APIs routinely add 2–5 seconds of latency to that final click — and every 100ms of delay measurably impacts conversion rates.

In this guide, we'll break down every layer of payment performance in Magento 2: from the gateway integration itself to how payment methods are loaded on the checkout page, how rate quotes are cached, and how you can offload slow operations to background processes.

Where Payment Latency Comes From

Before optimizing, you need to understand the four main sources of payment-related latency in Magento 2:

Gateway API calls — Authorize.net, Stripe, Adyen, or Mollie all require HTTP round-trips to external servers. These calls are synchronous by default and block the checkout response.
Payment method availability checks — Magento evaluates which payment methods are available for the current quote on every checkout page load. Each method can trigger its own logic (customer group, billing address, cart total checks).
Rate quote requests — Many gateways fetch transaction fees or currency conversion rates on every checkout load, not just when the customer selects "Place Order."
Payment method rendering — Each payment method injects its own JS component via payment-methods.js. Heavy JavaScript bundles for payment forms (iFrames, validation libraries, 3DS widgets) add to frontend rendering time.

The good news: every single one of these is fixable.

1. Cache Gateway Rate Quotes

Most payment gateways provide a "rate quote" or "fee quote" endpoint that calculates transaction costs based on cart total, currency, and customer group. The mistake most integrations make is calling this endpoint on every checkout page load.

If your cart total hasn't changed and your currency hasn't changed, the rate quote hasn't changed either. Cache it.

// In your payment method model or gateway client
public function getTransactionFee(Quote $quote): float
{
    $cacheKey = sprintf(
        'pay_gateway_fee_%s_%s_%s',
        $quote->getId(),
        $quote->getQuoteCurrencyCode(),
        (int) ($quote->getGrandTotal() * 100)
    );

    if ($cachedFee = $this->cache->load($cacheKey)) {
        return (float) $cachedFee;
    }

    $fee = $this->gatewayClient->fetchTransactionFee($quote);
    $this->cache->save(
        (string) $fee,
        $cacheKey,
        ['payment_fee', 'quote_' . $quote->getId()],
        3600 // 1 hour TTL
    );

    return $fee;
}

The cache tag quote_ followed by the quote ID ensures the fee is invalidated when the cart changes (adding/removing items updates the quote, which triggers tag-based cache invalidation). This alone can eliminate hundreds of milliseconds per checkout load.

2. Lazy-Load Payment Method Components

Magento 2's checkout renders all available payment methods on page load via the Magento_Checkout/js/view/payment UI component. Each method registers its renderer, validation rules, and potentially heavy JavaScript dependencies — even if the customer never selects that method.

For stores with 5+ payment methods (common in European markets: iDeal, Bancontact,信用卡, PayPal, Klarna...), this adds significant JavaScript parse and execution time.

The fix: code-split payment method renderers and load them on demand.

// Instead of requiring all payment renderers upfront in payment-methods.js
define([
    'uiComponent',
    'Magento_Checkout/js/model/payment/renderer-list'
], function (Component, rendererList) {
    'use strict';

    return Component.extend({
        initialize: function () {
            this._super();

            // Only register the default/preferred method eagerly
            rendererList.push({
                type: 'ideal',
                component: 'YourVendor_Payment/js/view/payment/method-renderer/ideal'
            });

            // Lazy-load other methods on selection
            this.lazyPaymentMethods.forEach(function (method) {
                require([method.component], function (renderer) {
                    rendererList.push({
                        type: method.type,
                        component: method.component
                    });
                });
            });

            return this;
        }
    });
});

Using require() with a dynamic callback defers the JavaScript load until the component is actually needed. For payment methods like Klarna or PayPal that bundle large SDKs, this can save 200–400KB of JavaScript on initial checkout render.

3. Set Aggressive Gateway Timeouts

A payment gateway that takes 30 seconds to respond is worse than one that fails immediately. Customers will abandon the checkout either way, but a fast failure lets you fall back to a secondary gateway or show a retry prompt.

Configure your gateway HTTP client with strict timeouts:

// In your gateway client configuration (di.xml or module config)
<type name="YourVendor\Payment\Model\Gateway\Http\Client">
    <arguments>
        <argument name="config" xsi:type="array">
            <item name="timeout" xsi:type="number">10</item>
            <item name="connect_timeout" xsi:type="number">5</item>
        </argument>
    </arguments>
</type>

And if you're using Guzzle or Symfony HTTP client directly:

$client = new \GuzzleHttp\Client([
    'timeout'         => 10,    // Total request timeout
    'connect_timeout' => 5,     // TCP connection timeout
]);

try {
    $response = $client->post($gatewayUrl, [
        'json' => $payload,
    ]);
} catch (\GuzzleHttp\Exception\ConnectException $e) {
    // Log and fallback — don't let the customer wait
    $this->logger->error('Payment gateway timeout', [
        'gateway' => $gatewayUrl,
        'error' => $e->getMessage(),
    ]);
    throw new \Magento\Framework\Exception\LocalizedException(
        __('Payment service unavailable. Please try again or choose a different payment method.')
    );
}

The key insight: a 10-second timeout is your safety net, not your target. If your gateway is consistently taking more than 3–4 seconds, you should investigate failover or async strategies (covered below).

4. Async Authorization for Supported Gateways

Some payment gateways — notably Mollie, Adyen, and Stripe — support async payment authorization. Instead of blocking the customer's browser while the gateway processes the payment, you:

Create a payment intent/transaction on the frontend (fast API call)
Redirect the customer to the success page immediately
The gateway sends a webhook to confirm the payment asynchronously
Magento processes the webhook via a message queue consumer

Here's the pattern:

// Frontend controller — create payment intent, return immediately
public function execute()
{
    $quote = $this->checkoutSession->getQuote();

    // Create payment intent (fast — ~500ms)
    $intent = $this->gatewayClient->createPaymentIntent([
        'amount' => $quote->getGrandTotal() * 100,
        'currency' => $quote->getQuoteCurrencyCode(),
        'metadata' => ['quote_id' => $quote->getId()],
    ]);

    // Place order as pending
    $order = $this->placeOrder($quote, $intent->getId());
    $order->setState(\Magento\Sales\Model\Order::STATE_PENDING_PAYMENT);
    $order->save();

    // Return intent to frontend for redirect
    return $this->jsonResponse([
        'intent_id' => $intent->getId(),
        'redirect_url' => $intent->getRedirectUrl(),
    ]);
}

// Webhook consumer — process async payment confirmation
// In etc/communication.xml and etc/queue_consumer.xml
public function processPaymentWebhook($paymentData)
{
    $order = $this->orderRepository->getByIncrementId($paymentData['order_id']);

    if ($paymentData['status'] === 'authorized') {
        $this->orderManagement->processPayment($order, $paymentData);
        $order->setState(\Magento\Sales\Model\Order::STATE_PROCESSING);
    } else {
        $order->setState(\Magento\Sales\Model\Order::STATE_CANCELED);
    }

    $this->orderRepository->save($order);
}

This pattern moves the slowest operation (gateway processing time) completely out of the customer's checkout flow. The customer sees the success page within 1–2 seconds of clicking "Place Order."

5. Optimize Payment Method Availability Checks

Magento 2 evaluates isActive() and isAvailable() for every payment method on every checkout page load. For stores with many payment methods, this creates a cascade of checks — some involving database queries (customer group validation, billing address country validation, min/max cart total validation).

Profile these checks:

# Enable profiler for the checkout page
bin/magento dev:profiler:enable html
# Load checkout, then check the profiler output
# Look for "PaymentMethod" entries in the call tree

Common bottlenecks:

Country validation that queries directory_country on every load — cache the country list per store view
Customer group rules that run separate queries per payment method — batch-load customer group data once
Min/max order total checks that re-read quote totals — use the already-calculated quote.grand_total instead of recalculating

If you have a custom payment method, ensure its isAvailable() method is O(1) and doesn't trigger any database queries:

public function isAvailable(\Magento\Quote\Api\Data\CartInterface $quote = null)
{
    // Use data already on the quote — no extra queries
    if ($quote === null || !$quote->getItemsCount()) {
        return false;
    }

    $grandTotal = (float) $quote->getGrandTotal();
    if ($grandTotal < $this->minOrderTotal || $grandTotal > $this->maxOrderTotal) {
        return false;
    }

    // Country check from cached data
    $countryCode = $quote->getBillingAddress()->getCountryId();
    if (!in_array($countryCode, $this->allowedCountries)) {
        return false;
    }

    return true;
}

6. Payment Method Template Optimization

Payment method HTML templates are rendered inline on the checkout page. For methods that include iFrame-based card inputs (e.g., Stripe Elements), these templates can be heavy.

Optimization strategies:

Defer 3DS widget loading — only load the 3DS challenge iframe when the customer triggers the "Place Order" action
Preconnect to payment gateway domains — add <link rel="preconnect"> for gateway API endpoints to warm up DNS/TLS connections before they're needed
Inline critical form elements — the card input fields should be in the initial HTML, while validation scripts and style assets can load asynchronously

Adding preconnect hints is a zero-effort win. Add this to your theme's default_head_blocks.xml:

<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <head>
        <link rel="preconnect" src="https://api.stripe.com" />
        <link rel="preconnect" src="https://js.stripe.com" />
        <link rel="preconnect" src="https://api.mollie.com" />
        <!-- Add your gateway domains -->
    </head>
</page>

For checkout-specific preconnects, create checkout_index_index.xml:

<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <head>
        <link rel="preconnect" src="https://api.stripe.com" />
        <link rel="preconnect" src="https://m.stripe.com" />
    </head>
</page>

7. Measure: Payment Performance Dashboard

You can't optimize what you don't measure. Create a simple admin dashboard widget that tracks:

Gateway response time (average, P95, P99) — measure from your gateway client
Gateway error rate — timeouts, 5xx responses, declined payments
Checkout completion time — from payment step render to order placement
Payment method selection distribution — which methods customers actually use

Log gateway timing in your client:

$start = microtime(true);
$response = $this->gatewayClient->execute($request);
$duration = (microtime(true) - $start) * 1000;

$this->logger->info('Payment gateway response', [
    'gateway' => $this->gatewayCode,
    'endpoint' => $request->getUri(),
    'duration_ms' => round($duration),
    'status' => $response->getStatusCode(),
]);

Forward these logs to a monitoring system (New Relic, Grafana, or even a simple cron-aggregated report) and set alerts for P95 latency above 3 seconds.

Conclusion

Payment performance is the last mile of your Magento 2 checkout — and the part where you have the least control, because you're depending on external services. The strategies that work are the ones that minimize synchronous external calls:

Cache rate quotes to avoid redundant gateway calls
Lazy-load payment method JavaScript to reduce frontend payload
Set aggressive timeouts so fast failures beat slow hangs
Use async authorization where your gateway supports it
Profile and optimize isAvailable() checks to prevent silent database queries
Preconnect to gateway domains for free TLS savings
Monitor everything — gateway latency is not static, it degrades under load

Every 100 milliseconds you shave off payment processing translates directly to recovered revenue. Start with caching rate quotes and setting timeouts — those two changes take an afternoon and typically save 1–2 seconds per checkout.

Magento 2 Setup:Upgrade Performance — Speed Up Slow Deployments

Magevanta — Thu, 13 Aug 2026 09:03:31 +0000

If you've ever watched bin/magento setup:upgrade run for 20 minutes on a production database while your deployment pipeline ticks away, you know the pain. On large Magento 2 installations with hundreds of modules and millions of records, setup:upgrade becomes the single biggest bottleneck in your CI/CD pipeline — often taking longer than the actual code deployment, static content generation, and cache warming combined.

The good news? Most of that time is wasted on operations you can optimize, skip, or parallelize. Let's break down exactly what setup:upgrade does, where it spends its time, and how to make it fast.

What Setup:Upgrade Actually Does

setup:upgrade is Magento's schema and data migration tool. When you deploy new code, it:

Checks module versions — reads every module's module.xml and db_schema.xml
Runs schema upgrades — executes InstallSchema, UpgradeSchema, and declarative schema patches
Runs data patches — executes RecurringDataPatch and module-level data patches
Updates setup_module table — records the new module version
Runs DI compilation — regenerates generated/ (if in production mode)
Flushes cache types — invalidates configs, layout, block_html, full_page

Steps 2 and 3 are where most of the time goes. If you have modules with poorly written data patches, N+1 queries in upgrade scripts, or schema operations that don't use batch inserts, setup:upgrade can crawl.

Step 1: Profile Before You Optimize

Don't guess — measure. Run setup:upgrade with the verbose flag and capture timestamps:

bin/magento setup:upgrade --verbose 2>&1 | while IFS= read -r line; do
  echo "$(date '+%H:%M:%S') $line"
done | tee /tmp/setup-upgrade.log

This gives you a timestamped log showing exactly which modules take the longest. Look for:

Long gaps between module lines — a single module's upgrade is slow
Repeating patterns — a third-party module doing per-row inserts in a loop
"Data upgrade..." messages — data patches running row-by-row instead of in bulk

For a deeper dive, enable MySQL's slow query log during the upgrade:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;

Run setup:upgrade, then check mysql.slow_log for queries taking more than a second. You'll often find the same few queries repeated hundreds of times.

Step 2: Eliminate Unnecessary Module Upgrades

Not every deployment changes every module. If only 3 modules changed, why upgrade all 300?

Magento doesn't give you a native --only-module flag, but you can work around it. First, identify which modules actually changed version:

# Compare deployed versions vs new code versions
cd /var/www/html
bin/magento module:status --enabled | while read module; do
  code_version=$(grep -oP 'setup_version="[0-9.]+"' app/code/*/etc/module.xml 2>/dev/null | grep -oP '[0-9.]+' | head -1)
  db_version=$(bin/magento setup:db:status --module="$module" 2>/dev/null | grep -oP 'version: [0-9.]+' | grep -oP '[0-9.]+')
  [ "$code_version" != "$db_version" ] && echo "$module: $db_version → $code_version"
done

If fewer than 10 modules changed, consider running schema patches manually or using a targeted approach. For full automation, build this check into your deploy script and skip setup:upgrade entirely when no modules changed version.

Step 3: Optimize Data Patches

Data patches (Patch/Schema and Patch/Data) are the #1 culprit for slow upgrades. Common anti-patterns:

Anti-pattern 1: Per-row inserts in a loop

// BAD — runs 50,000 queries
foreach ($productIds as $id) {
    $this->connection->insert('catalog_product_entity_int', [
        'attribute_id' => $attrId,
        'entity_id' => $id,
        'value' => 1,
    ]);
}

// GOOD — single batch insert
$rows = array_map(function ($id) use ($attrId) {
    return ['attribute_id' => $attrId, 'entity_id' => $id, 'value' => 1];
}, $productIds);
$this->connection->insertMultiple('catalog_product_entity_int', $rows);

Anti-pattern 2: Loading full collections

// BAD — loads 50K products into memory
$products = $this->productCollectionFactory->create()->load();
foreach ($products as $product) { ... }

// GOOD — use direct SQL or iterator
$select = $this->connection->select()->from('catalog_product_entity', ['entity_id']);
$iterator = $this->connection->query($select);
while ($batch = $this->fetchBatch($iterator, 1000)) { ... }

Anti-pattern 3: Missing dependency declarations

If PatchB depends on PatchA, but the dependency isn't declared, Magento may run them in parallel or in the wrong order. The patch system uses getDependencies() to sequence execution. Missing dependencies cause deadlocks on large installs.

public static function getDependencies()
{
    return [
        \Vendor\Module\Setup\Patch\Data\AddColumnToProducts::class,
    ];
}

Audit your third-party modules' data patches — you'll be surprised how many have these anti-patterns. If vendor patches are slow, consider wrapping them or running them pre-deployment during off-peak hours.

Step 4: Mark Already-Applied Patches (Skip Redundant Work)

If you know certain data patches have already run and don't need to run again, you can mark them as applied in the database:

INSERT INTO setup_patches SET patch_name = 'Vendor\\Module\\Setup\\Patch\\Data\\SlowPatch',
  patch_type = 'data', patch_version = '1.0.0', patch_id = NULL
ON DUPLICATE KEY UPDATE patch_name = patch_name;

This skips the patch on the next setup:upgrade run. Only do this if you're certain the patch has been applied — check with your deployment logs first.

For a safer approach, use Magento's --safe-mode=1 flag during staging deployments to verify patches before running them in production.

Step 5: Declarative Schema Over Upgrade Scripts

Declarative schema (db_schema.xml) is significantly faster than UpgradeSchema.php scripts because Magento generates a single diff and applies it in batch, rather than running arbitrary PHP per module.

If you maintain custom modules, migrate from UpgradeSchema.php to db_schema.xml. The migration is straightforward:

Create etc/db_schema.xml matching your current schema
Add <schema> declaration in module.xml
Run bin/magento setup:upgrade --convert-old-scripts=1 to auto-generate the schema from existing upgrade scripts
Review and test the generated db_schema.xml

Magento handles the diff, generates CREATE TABLE, ALTER TABLE, and DROP TABLE statements automatically. No PHP execution needed per upgrade cycle — Magento compares the declarative schema against the database and only runs the delta.

Step 6: Skip DI Compilation During Upgrade

If you generate compiled DI separately (in your CI pipeline), you don't need setup:upgrade to do it. Run:

bin/magento setup:upgrade --keep-generated

This skips the generated/ regeneration step, which can save several minutes on large installs. Just make sure you run setup:di:compile in your CI pipeline before deploying:

# In your CI pipeline
bin/magento setup:di:compile
# Deploy the generated/ directory with the code

# On the server, during deploy hook
bin/magento setup:upgrade --keep-generated

Important: Only use --keep-generated if you've already compiled DI for the exact code version being deployed. Mismatched generated code causes runtime errors.

Step 7: Parallelize Where Possible

Magento's setup:upgrade runs modules sequentially. While you can't natively parallelize it, you can:

Run schema patches and DI compilation in parallel — schema patches finish first, while DI compilation runs in a separate process
Pre-warm cache during upgrade — use a background process to warm full page cache while upgrade runs
Use maintenance mode strategically — put the site in maintenance, run upgrade, then take it out. Don't leave the site live during upgrade.

bin/magento maintenance:enable
bin/magento setup:upgrade --keep-generated &
bin/magento setup:di:compile &
wait
bin/magento cache:clean
bin/magento maintenance:disable

Step 8: Database-Level Optimizations

The setup:upgrade process is I/O-bound on MySQL. These database-side optimizations make a measurable difference:

Increase innodb_buffer_pool_size — ensure the entire setup_module and setup_patches tables fit in memory
Tune innodb_flush_log_at_trx_commit — setting to 2 during maintenance windows gives a 2-3x write speedup at the cost of ACID guarantees (safe for deployment windows)
Drop unused indexes before upgrade — if a data patch recreates indexes, dropping them first and recreating after is faster than incremental updates
Increase innodb_io_capacity — during maintenance, allow MySQL to use more I/O throughput for faster table operations

-- Temporarily boost InnoDB performance during maintenance
SET GLOBAL innodb_flush_log_at_trx_commit = 2;
SET GLOBAL innodb_io_capacity = 2000;
SET GLOBAL innodb_io_capacity_max = 4000;

-- After upgrade completes
SET GLOBAL innodb_flush_log_at_trx_commit = 1;
SET GLOBAL innodb_io_capacity = 200;
SET GLOBAL innodb_io_capacity_max = 2000;

Remember to reset these values after the upgrade completes. Running with relaxed durability settings permanently risks data loss on power failure.

Step 9: Audit Third-Party Modules

Third-party modules often ship with heavy upgrade scripts. Common offenders:

ERP integrations — creating custom tables with initial data seed
Payment gateways — adding columns to sales_order with default values on large tables
Search extensions — rebuilding entire index tables during upgrade

Audit the Setup/Patch/ directories of your installed modules. If you find slow patches, contact the vendor or patch them locally:

# Find all data patches across vendor modules
find vendor/ -path '*/Setup/Patch/Data/*.php' -exec basename {} \;

For the worst offenders, you can often refactor the patch to use batch operations and submit a PR upstream. Many vendors are responsive to performance PRs, especially if you include benchmarks showing the before/after timings.

Step 10: Track Upgrade Duration Over Time

Once you've optimized, keep an eye on regressions. Log setup:upgrade duration on every deployment:

start=$(date +%s)
bin/magento setup:upgrade --keep-generated
end=$(date +%s)
duration=$((end - start))
echo "$(date -Iseconds) setup_upgrade_duration=${duration}s" >> /var/log/magento-deployments.log

Graph this in Grafana, Datadog, or your monitoring tool of choice. When a new deployment suddenly takes 2x longer, you'll know immediately which module introduced a slow patch. Set up alerts for when upgrade duration exceeds your baseline by more than 50%.

Conclusion

setup:upgrade doesn't have to be the bottleneck in your deployment pipeline. By profiling what's slow, optimizing data patches, migrating to declarative schema, skipping unnecessary work, and parallelizing where you can, large Magento 2 installs can go from 20-minute upgrades to under 5 minutes.

The key takeaways:

Profile first — don't optimize blind, use verbose logging and MySQL slow query log
Batch everything — per-row operations in data patches are the #1 performance killer
Use --keep-generated — skip DI compilation during upgrade if it's done in CI
Migrate to declarative schema — it's faster, declarative, and auto-generates diffs
Audit third-party modules — vendor patches are often the worst offenders
Track duration over time — catch regressions before they become deployment-day emergencies

Fast deployments mean more deployments. More deployments mean smaller changes, faster feedback, and less risk. Every minute you shave off setup:upgrade pays dividends across your entire development workflow.

Magento 2 Email Performance Optimization: From SMTP Bottlenecks to Async Sending

Magevanta — Wed, 12 Aug 2026 09:03:57 +0000

Email is often the forgotten performance bottleneck in Magento 2. While stores obsess over page load times and database queries, the email subsystem quietly drags down checkout completion, order processing, and cron execution. A single slow SMTP handshake can add seconds to every order placement. Multiply that by hundreds of orders per hour and you have a real problem.

In this post we'll diagnose the most common email performance issues and implement fixes that actually move the needle.

The Hidden Cost of Synchronous Email

By default, Magento 2 sends emails synchronously during the request lifecycle. When a customer places an order, the system:

Renders the email template (PHP + HTML compilation)
Opens an SMTP connection
Authenticates and transmits the message
Waits for server acknowledgement
Closes the connection

Steps 2-4 happen inside the same request that renders the order success page. If your SMTP server is 150ms away and takes 300ms to accept a message, every customer waits an extra 300-500ms after clicking "Place Order." During peak traffic this compounds into connection exhaustion and timeout errors.

The worst part? These delays rarely show up in standard profiling because they're classified as "network I/O" rather than Magento code execution.

Fix 1: Enable Async Email Sending

Magento 2.4+ includes built-in support for asynchronous email via RabbitMQ or MySQL message queues. This decouples email transmission from the frontend request.

Enable it in app/etc/env.php:

'system' => [
    'default' => [
        'sales_email' => [
            'general' => [
                'async_sending' => 1
            ]
        ]
    ]
]

Or via CLI for immediate effect:

bin/magento config:set sales_email/general/async_sending 1
bin/magento cache:clean config

With async sending enabled, order confirmation emails are queued immediately and processed by a background consumer. The customer sees the success page instantly while the email ships separately.

Verify the consumer is running:

bin/magento queue:consumers:start sales.sendOrderEmails

For production, register this as a systemd service or Supervisord process. Without a running consumer, emails accumulate in the queue indefinitely.

Fix 2: SMTP Connection Pooling with External Providers

Default Magento uses PHP's mail() function or opens a fresh SMTP connection per email. Both are inefficient at scale.

Switch to a transactional email service (Mailgun, SendGrid, AWS SES, Postmark) and configure connection reuse. Most support HTTP APIs that are faster than SMTP handshakes, but if you must use SMTP, enable persistent connections.

For SendGrid via SMTP in app/etc/env.php:

'system' => [
    'default' => [
        'system' => [
            'smtp' => [
                'host' => 'smtp.sendgrid.net',
                'port' => 587,
                'auth' => 'login',
                'username' => 'apikey',
                'password' => 'SG.your-api-key-here',
                'ssl' => 'tls'
            ]
        ]
    ]
]

Better yet, use a Magento module that calls HTTP APIs directly. HTTP requests have lower overhead than SMTP connection negotiation and support keep-alive pooling natively.

Fix 3: Template Compilation Cache

Email templates in Magento 2 are PHP-based and compiled at runtime. The first time a template renders, Magento parses the .html file, extracts directives ({{var order.getIncrementId()}}), and generates executable PHP code.

This compilation is cached, but the cache is filesystem-based and can be slow on NFS or shared storage. Ensure template compilation cache is stored in Redis:

'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'Magento\Framework\Cache\Backend\Redis',
            'backend_options' => [
                'server' => '127.0.0.1',
                'port' => '6379',
                'database' => 0,
                'password' => '',
                'compress_data' => 1,
                'compression_lib' => 'gzip'
            ]
        ]
    ]
]

Warm the email template cache after deployments by triggering a test email or visiting the template preview in Admin > Marketing > Email Templates.

Fix 4: Batch Processing for Bulk Operations

Bulk actions like invoice generation, shipment creation, or newsletter blasts trigger dozens of emails in rapid succession. Each email in isolation is fast; together they overwhelm the mail subsystem.

For newsletter sends or promotional campaigns, avoid Magento's native email loop. Instead, export recipient lists to your transactional email provider's batch API. SendGrid, Mailgun, and SES all support batch endpoints that accept thousands of recipients in a single request.

For operational emails (invoices, shipments), implement a custom batch queue:

class BatchEmailSender
{
    private $batch = [];
    private $batchSize = 50;

    public function queueEmail($templateId, $vars, $to)
    {
        $this->batch[] = compact('templateId', 'vars', 'to');

        if (count($this->batch) >= $this->batchSize) {
            $this->flush();
        }
    }

    public function flush()
    {
        if (empty($this->batch)) {
            return;
        }

        // Send via provider's batch API or grouped SMTP transaction
        foreach ($this->batch as $email) {
            // Process
        }

        $this->batch = [];
    }
}

Hook this into invoice and shipment mass-action controllers to reduce SMTP round-trips by 50x.

Fix 5: Eliminate Unnecessary Emails

Every module that hooks into sales_order_place_after or checkout_submit_all_after can trigger emails. Audit your observers:

grep -r "transportBuilder" app/code/ vendor/ --include="*.php" | grep -v Test

For each match, ask: does this email need to send immediately? Can it be deferred? Can it be suppressed entirely?

Common offenders:

Third-party review request modules — sending 5 minutes post-purchase via cron. Move to daily batch.
Inventory update notifications — admins don't need real-time stock alerts. Digest them hourly.
Duplicate order confirmations — some payment modules send their own confirmation alongside Magento's. Disable one.

Fix 6: Monitor the Email Queue

You can't optimize what you don't measure. Add queue depth monitoring to your observability stack:

# Check RabbitMQ queue depth (if using RabbitMQ)
rabbitmqctl list_queues name messages | grep sales

# Check MySQL queue (if using db queue)
mysql -e "SELECT COUNT(*) FROM queue_message WHERE queue_id = (SELECT id FROM queue WHERE name = 'sales.sendOrderEmails')"

Alert when queue depth exceeds 100 messages or oldest message age exceeds 5 minutes. These thresholds catch consumer failures before customers complain about missing order emails.

For SMTP-level monitoring, track these metrics per email provider:

Delivery rate (should be >97%)
Bounce rate (keep <2%)
Average send latency (target <500ms from queue to acceptance)
Daily volume vs. rate limits

Fix 7: Tune Cron for Email-Heavy Jobs

Magento's cron handles email consumers, reminder sends, and report generation. On email-heavy stores, dedicate a separate cron group:

<!-- app/etc/cron_groups.xml -->
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <group id="email">
        <schedule_generate_every>1</schedule_generate_every>
        <schedule_ahead_for>4</schedule_ahead_for>
        <schedule_lifetime>2</schedule_lifetime>
        <history_cleanup_every>10</history_cleanup_every>
        <history_success_lifetime>60</history_success_lifetime>
        <history_failure_lifetime>600</history_failure_lifetime>
        <use_separate_process>1</use_separate_process>
    </group>
</config>

Register email consumers under this group to prevent email backlog from blocking catalog price rule updates or indexer runs.

Summary

Email performance is request-blocking, queue-dependent, and often invisible until it breaks. The fixes are straightforward but require changing default behaviors:

Issue	Fix	Impact
Synchronous SMTP in checkout	Enable async sending	-300-500ms per order
Fresh SMTP connection per email	Connection pooling / HTTP API	-200ms per email
Template compilation overhead	Redis cache + pre-warm	-50ms first render
Bulk email loops	Batch processing	10-50x throughput gain
Unnecessary email triggers	Audit & suppress observers	Reduced queue pressure
Consumer failures	Queue depth monitoring	Prevent silent email loss
Cron contention	Dedicated email cron group	Isolated email processing

Start with async sending — it's a single configuration change with immediate customer-facing impact. Then layer in SMTP optimization and monitoring. Your checkout completion rate will thank you.

Have you diagnosed email bottlenecks in your Magento store? Share your SMTP provider and latency numbers — the community needs more real-world benchmarks.

Magento 2 Product Relations Performance: Fixing Upsells, Crosssells & Related Products at Scale

Magevanta — Sun, 09 Aug 2026 09:03:58 +0000

Every Magento 2 product detail page loads three types of product relations: upsells, crosssells, and related products. On a small catalog, you barely notice them. On a large catalog with thousands of products and complex rule-based relations, they become one of the most expensive parts of your product page — and one of the hardest to debug.

This guide breaks down how Magento 2 loads product relations, where the performance bottlenecks hide, and what you can do to keep your product pages fast even when every product has dozens of relations.

How Magento 2 Loads Product Relations

Magento 2 stores product relations in the catalog_product_link table, along with the catalog_product_link_type and catalog_product_link_attribute tables. The three relation types — related (1), upsell (2), and crosssell (3) — are all stored in the same structure.

When a customer opens a product detail page, Magento goes through this sequence:

Load the main product via the product repository
Fetch all links for the product from catalog_product_link where product_id = <current_product>
Load each linked product as a full product entity (EAV load)
Apply pricing — including tier prices, catalog price rules, and tax calculations
Load product images for each relation (gallery API)
Apply inventory status — check stock for each related product
Render the relation blocks (related products list, upsell block, crosssell block)

Steps 3–6 are where things go wrong. Each linked product triggers a full EAV load, a price calculation, and an inventory check. If a product has 20 related products, that's 20 separate EAV queries, 20 price calculations, and 20 stock checks — most of which happen inside loops that Magento doesn't batch.

The N+1 Problem in Product Relations

The core issue is an N+1 query pattern. Magento loads the link collection (1 query), then loads each linked product individually (N queries). On a product with 15 related products, that's 16 queries minimum — and in practice, many more when you factor in EAV attributes, pricing, and inventory.

Here's what the query log looks like on a typical PDP with 12 related products:

SELECT * FROM catalog_product_link WHERE product_id = 1234;
-- 12 rows returned

-- For each linked product (×12):
SELECT * FROM catalog_product_entity WHERE entity_id = <link_id>;
SELECT * FROM catalog_product_entity_varchar WHERE entity_id = <link_id>;
SELECT * FROM catalog_product_entity_decimal WHERE entity_id = <link_id>;
SELECT * FROM catalog_product_index_price WHERE entity_id = <link_id>;
SELECT * FROM cataloginventory_stock_status WHERE product_id = <link_id>;

That's roughly 60+ queries just for the related products block. On a high-traffic store, this adds up to significant database pressure.

Diagnosing the Problem

Before optimizing, measure the actual impact. You need to know exactly how much time your product relations are adding to the PDP.

Enable the Database Profiler

// In app/etc/env.php or a temporary diagnostic module
'profiler' => [
    'class' => \Magento\Framework\DB\Profiler::class,
    'enabled' => true,
]

Or use the built-in profiler via MAGE_PROFILER=1 in your .htaccess or Nginx config:

SetEnv MAGE_PROFILER 1

Look for query patterns that repeat for each linked product. Count the queries attributed to catalog_product_link joins and subsequent EAV loads.

Use Blackfire or New Relic

Trace a product page with 10+ relations and look for:

The getLinkCollection() call tree
Time spent in \Magento\Catalog\Model\Product\Link::getLinkedProductCollection
Total EAV load time for linked products
Price calculation overhead (getPriceInfo(), getFinalPrice())

If your relations loading takes more than 200ms, you have a problem worth fixing.

Optimization 1: Limit the Number of Loaded Relations

The simplest fix is also the most effective: load fewer relations. Magento lets you configure how many related/upsell/crosssell products to display, but the underlying collection still loads all of them before slicing.

Reduce the Link Collection Size

In your product blocks, limit the collection early — before the EAV load happens:

// In a custom block that extends \Magento\Catalog\Block\Product\ProductList\Related
protected function _prepareData()
{
    $this->_itemCollection = $this->_productFactory->create()
        ->getCollection()
        ->addAttributeToSelect(['name', 'price', 'small_image', 'short_description'])
        ->joinField(
            'link_id',
            'catalog_product_link',
            'link_id',
            'product_id=entity_id',
            '{{table}}.linked_product_id=' . $this->getProduct()->getId(),
            'inner'
        )
        ->addLinkType(\Magento\Catalog\Model\Product\Link::LINK_TYPE_RELATED)
        ->setPageSize(6)  // ← Critical: limit before EAV load
        ->setCurPage(1);

    $this->_itemCollection->addStoreFilter();
    $this->_itemCollection->addPriceData();
    $this->_itemCollection->addTaxPercents();
    $this->_itemCollection->addUrlRewrite();

    return $this;
}

The key is setPageSize(6) — this limits the SQL query itself, so Magento only loads 6 products from the database instead of loading all 20 and displaying 6.

Audit Product Relations in Bulk

If your merchandisers are adding 30+ related products per product, you have a data problem. Run this query to find the worst offenders:

SELECT
    product_id,
    link_type,
    COUNT(*) as relation_count
FROM catalog_product_link
GROUP BY product_id, link_type
HAVING relation_count > 10
ORDER BY relation_count DESC
LIMIT 50;

Any product with more than 10 relations of a single type is a candidate for cleanup. In most storefronts, 4–6 related products and 3–4 crosssells is plenty.

Optimization 2: Select Only the Attributes You Need

By default, Magento loads the full EAV entity for each linked product — every attribute, including long descriptions, gallery data, and attributes that only matter on the PDP itself. For a relation block, you only need a handful of attributes.

Use `addAttributeToSelect` Explicitly

$this->_itemCollection
    ->addAttributeToSelect(['name', 'price', 'small_image', 'short_description', 'url_key'])
    // Do NOT use addAttributeToSelect('*') — it loads every attribute
    ;

This alone can cut the EAV query count by 60–80% per linked product, especially on catalogs with many custom attributes.

Disable the Flat Catalog for Relation Collections

The flat catalog (catalog_product_flat) is often recommended for performance, but it creates wide tables with every attribute. When Magento loads related products via the flat table, it selects all flat columns — even if you only need 5 attributes.

For relation collections, bypass the flat catalog:

$this->_itemCollection->setStoreId($this->_storeManager->getStore()->getId())
    ->addAttributeToSelect(['name', 'price', 'small_image', 'short_description'])
    ->setFlag('disable_flat_catalog', true);  // Force EAV with limited attribute selection

With limited addAttributeToSelect, EAV is actually faster than flat for relation blocks because it only queries the specific attribute tables instead of joining the entire flat row.

Optimization 3: Cache the Rendered Relation Blocks

Product relations are ideal candidates for block-level caching because they change rarely. Magento's full page cache already handles PDP blocks, but if you're running without FPC (e.g., logged-in customers), relation blocks can bypass cache entirely.

Add Cache Key Data to Relation Blocks

// In your custom relation block
protected function getCacheKeyInfo()
{
    return [
        'PRODUCT_RELATIONS',
        $this->getProduct()->getId(),
        $this->_storeManager->getStore()->getId(),
        $this->getLinkType(),
        $this->getPageSize() ?? 6,
    ];
}

public function getCacheLifetime()
{
    return 86400; // Cache for 24 hours
}

Invalidate on Product Relation Changes

Hook into the product save event to invalidate cached relation blocks:

<!-- etc/frontend/events.xml -->
<event name="catalog_product_save_after">
    <observer name="invalidate_product_relations_cache"
              instance="Vendor\Module\Observer\InvalidateProductRelationsCache"/>
</event>

class InvalidateProductRelationsCache implements \Magento\Framework\Event\ObserverInterface
{
    private $cache;

    public function __construct(\Magento\Framework\App\CacheInterface $cache)
    {
        $this->cache = $cache;
    }

    public function execute(\Magento\Framework\Event\Observer $observer)
    {
        $product = $observer->getEvent()->getProduct();
        // Invalidate this product's relation blocks
        $this->cache->remove('PRODUCT_RELATIONS_' . $product->getId() . '_');
    }
}

Optimization 4: Preload Product Data with a Single Query

The most impactful optimization is replacing the N+1 pattern with a single batch query. Instead of loading each linked product individually, load them all in one go.

Custom Batch Loader

class BatchProductLoader
{
    private ProductRepositoryInterface $productRepository;
    private array $loadedProducts = [];

    public function __construct(
        ProductRepositoryInterface $productRepository
    ) {
        $this->productRepository = $productRepository;
    }

    public function loadProducts(array $productIds, int $storeId): array
    {
        // Filter out already-loaded products
        $neededIds = array_diff($productIds, array_keys($this->loadedProducts));

        if (empty($neededIds)) {
            return array_intersect_key($this->loadedProducts, array_flip($productIds));
        }

        $collection = $this->productRepository->create()->getCollection()
            ->addAttributeToSelect(['name', 'price', 'small_image', 'short_description', 'url_key'])
            ->addStoreFilter($storeId)
            ->addUrlRewrite()
            ->addFieldToFilter('entity_id', ['in' => $neededIds]);

        $collection->addPriceData();
        $collection->addTierPriceData();
        $collection->addTaxPercents();

        foreach ($collection as $product) {
            $this->loadedProducts[$product->getId()] = $product;
        }

        return array_intersect_key($this->loadedProducts, array_flip($productIds));
    }
}

By injecting this loader and using it in your relation blocks, you replace N individual EAV loads with one collection query that fetches all linked products at once. The price, tax, and URL rewrite data are also loaded in batch.

Optimization 5: Replace Manual Relations with Rule-Based Loading

Manual product relations (where a merchandiser manually links products) don't scale. When every product needs 6 related products and you have 10,000 products, that's 60,000 manual links to maintain.

Rule-based relations generate the related products block dynamically based on shared attributes:

$this->_itemCollection = $this->_productFactory->create()
    ->getCollection()
    ->addAttributeToSelect(['name', 'price', 'small_image', 'short_description'])
    ->addAttributeToFilter('attribute_set_id', $this->getProduct()->getAttributeSetId())
    ->addAttributeToFilter('entity_id', ['neq' => $this->getProduct()->getId()])
    ->setPageSize(6)
    ->setCurPage(1)
    ->addStoreFilter()
    ->addPriceData()
    ->addUrlRewrite();

This eliminates the catalog_product_link table entirely and generates relations from shared attributes (same category, same brand, same attribute set). The collection query is a single indexed lookup — no N+1 pattern, no manual data entry.

Use the Sales Rule Approach

For even better results, use sales data to generate relations. Products that were frequently bought together make excellent crosssell recommendations:

SELECT
    soi2.product_id,
    COUNT(*) as frequency
FROM sales_order_item soi1
JOIN sales_order_item soi2 ON soi1.order_id = soi2.order_id
WHERE soi1.product_id = ?
  AND soi2.product_id != soi1.product_id
  AND soi2.product_type = 'simple'
GROUP BY soi2.product_id
ORDER BY frequency DESC
LIMIT 5;

Cache the result per product and regenerate nightly via a cron job. This approach eliminates the link table entirely and shows products that customers actually buy together.

Optimization 6: Disable Unused Relation Types

Not every store uses all three relation types. If you don't use upsells on your storefront, disable the block entirely — don't let the system load products that will never be displayed.

Disable Blocks via Layout XML

<!-- In your theme's layout override: Magento_Catalog/layout/catalog_product_view.xml -->
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <body>
        <!-- Remove upsell block entirely -->
        <referenceBlock name="product.info.upsell" remove="true"/>
        <!-- Or remove crosssell -->
        <referenceBlock name="checkout.cart.crosssell" remove="true"/>
    </body>
</page>

This prevents the block from being created, the collection from being initialized, and the queries from running. It's a free win if the block goes unused.

Optimization 7: Lazy-Load Relations via AJAX

For product pages where relations are nice-to-have but not critical, load them asynchronously after the main page renders. This keeps the initial TTFB and LCP fast.

Create an AJAX Endpoint

// In a custom controller: Vendor\Module\Controller\Product\Related
public function execute()
{
    $productId = (int)$this->getRequest()->getParam('id');
    $product = $this->productRepository->getById($productId);

    $collection = $product->getRelatedProductCollection()
        ->addAttributeToSelect(['name', 'price', 'small_image', 'short_description'])
        ->setPageSize(6)
        ->addStoreFilter()
        ->addPriceData()
        ->addUrlRewrite();

    $data = [];
    foreach ($collection as $related) {
        $data[] = [
            'name' => $related->getName(),
            'price' => $related->getFinalPrice(),
            'image' => $this->imageHelper->init($related, 'product_page_image_small')->getUrl(),
            'url' => $related->getProductUrl(),
        ];
    }

    return $this->jsonResponse(['items' => $data]);
}

Load via JavaScript on the Frontend

define(['jquery'], function($) {
    $(document).ready(function() {
        var productId = $('[data-product-id]').data('product-id');
        $.get('/rest/V1/custom/related/' + productId, function(response) {
            if (response.items.length) {
                var html = response.items.map(function(item) {
                    return '<div class="related-product">' +
                        '<a href="' + item.url + '">' +
                        '<img src="' + item.image + '" alt="' + item.name + '">' +
                        '<span>' + item.name + '</span>' +
                        '<span class="price">€' + item.price + '</span>' +
                        '</a></div>';
                }).join('');
                $('.related-products-container').html(html);
            }
        });
    });
});

This shifts the relation loading off the critical rendering path entirely. The main product page renders fast, and relations load progressively — improving Core Web Vitals while keeping the upsell/crosssell functionality intact.

Optimization 8: Inventory and Price Loading Optimization

Two expensive operations happen for each linked product: stock status check and price calculation. Both involve database queries and computation that multiply across all relations.

Batch Stock Status

Magento's stock status indexer already writes to cataloginventory_stock_status — make sure linked products are reading from the index, not the live stock tables. With MSI installed, ensure the stock status indexer is up to date:

bin/magento indexer:reindex inventory
bin/magento indexer:set-status realtime cataloginventory_stock_status

For relation blocks, use the indexed status directly:

$this->_itemCollection
    ->joinField(
        'is_in_stock',
        'cataloginventory_stock_status',
        'stock_status',
        'product_id=entity_id',
        '{{table}}.stock_id=1 AND {{table}}.website_id=' . $this->_storeManager->getStore()->getWebsiteId(),
        'inner'
    )
    ->addFieldToFilter('is_in_stock', ['eq' => 1]);

This filters out out-of-stock products at the SQL level, avoiding loading products that would only be hidden later.

Cache Price Calculations

Price calculation for linked products involves catalog price rules, tier prices, and tax. Cache the final price per product per customer group:

// Use the price index table directly instead of calculating on-the-fly
$this->_itemCollection
    ->joinField(
        'final_price',
        'catalog_product_index_price',
        'final_price',
        'entity_id=entity_id',
        '{{table}}.customer_group_id=0 AND {{table}}.website_id=' . $websiteId,
        'inner'
    );

Reading from the price index table is a single join — far cheaper than running the full price calculation pipeline for each product.

Checklist: Product Relations Performance Audit

Run through this checklist to audit your store:

Count relations per product — any product with more than 8 relations of one type needs cleanup
Profile a PDP with 10+ relations — measure query count and total time
Limit addAttributeToSelect to only needed attributes (name, price, image, url_key, short_description)
Set setPageSize() on relation collections to limit at SQL level
Remove unused relation blocks via layout XML overrides
Add block-level caching with proper cache key and invalidation
Consider AJAX lazy-loading for non-critical relations
Use indexed price and stock data instead of live calculations
Consider rule-based relations to eliminate manual link maintenance
Reindex regularly — stale price and stock indexes force fallback to live calculation

Conclusion

Product relations are one of those features that feels free — you just link some products in the admin and they appear on the storefront. But the underlying query pattern is fundamentally inefficient: for each relation, Magento loads a full product entity, calculates pricing, checks stock, and renders a block. Multiply that by 10–20 products per page, and you've added hundreds of milliseconds to every product detail page.

The optimizations in this guide range from quick wins (limiting page size, reducing attribute selection) to architectural changes (batch loading, AJAX deferred loading, rule-based relations). Start with the quick wins on your worst-performing product pages, measure the improvement, and work toward the architectural changes as your catalog grows.

Remember: a product page that loads in 300ms with 6 well-chosen related products will convert better than a page that loads in 1.2s with 20 related products that the customer scrolls past anyway. Fewer, faster, better.

DEV Community: Magevanta

Magento 2 Linux Server Tuning: Kernel, Filesystem & I/O Settings That Actually Matter

Why the OS layer matters for Magento

1. Filesystem: ext4 vs XFS and mount options

2. I/O scheduler: know what you're running on

3. Memory: swappiness, dirty pages and THP

4. CPU governor: stop letting the kernel downclock your store

5. File descriptor limits: the silent 1024-cap

6. Just use tuned: throughput-performance

7. What to measure after applying

The checklist

The honest bottom line

Magento 2 Product Reviews Performance: The Hidden Cron & N+1 Bottleneck

How reviews are stored

The 15-minute aggregation cron (the real killer)

The N+1 on listings and product pages

The slow admin grid

Cache behavior: review bursts are cache churn

The checklist

Magento 2 PHP 8.4 Upgrade: Real Performance Gains & a Safe Migration Checklist

What PHP 8.4 delivers (the honest version)

JIT: why Magento mostly ignores it

Which Magento supports PHP 8.4

The upgrade checklist

1. Know what you're running

2. Fix composer constraints

3. Deprecation sweep with static analysis

4. Don't forget the extensions

5. Measure before, measure after

6. Rollback plan

The bottom line

Magento 2 Price Index: How Prices Are Stored, Cached & Why Reindexing Is Slow

How Magento stores prices (the part nobody reads)

What the price index actually is

Why it's slow (the real reasons)

1. It re-evaluates every product, not just changed ones

2. Configurable products are a multiplier

3. Catalog price rules force full re-evaluation

4. It's CPU-, I/O- and memory-bound all at once

Measure before you touch anything

Strategies that actually help

Strategy 1 — Question whether the price indexer should exist at all

Strategy 2 — Feed the database properly

Strategy 3 — Run it at the right time, the right way

Strategy 4 — Reduce the multiplication

Strategy 5 — Don't hand-edit the price tables (stop the nightmare)

A note on partial reindexing and Mview

The practical checklist

Final word

Magento 2 Sales Order Performance: Grid Indexing, Order Loading & Bulk Operations

How Magento 2 Stores and Loads Orders

1. The Sales Grid Indexer Is Your First Bottleneck

2. Grid Bloat, Orphans and Table Maintenance

3. N+1 Order Loading — the Hidden Admin Killer

4. Bulk Operations: Exports, Mass Actions and ERP Sync

5. Optimizing the Admin Grid Itself

6. Monitoring so It Never Sneaks Up Again

The Checklist

Magento 2 Media Storage Performance: Database, Filesystem or S3?

How Magento 2 Stores Media (Under the Hood)

Performance Trap #1: Inodes and Directory Scalability

Performance Trap #2: On-the-Fly Image Resizing Races

Performance Trap #3: The Database Storage Mode

Performance Trap #4: Object Storage (S3) — The Scalable Answer

Performance Trap #5: The Media Gallery Table Itself

A Decision Framework for Your Store

Wrapping Up

Magento 2 Wishlist Performance: Taming the N+1 Query Beast

Why the Wishlist Is Expensive by Design

The Real Culprit You're Ignoring: The Sidebar

How to Measure the Damage

The Fixes, Ranked by Impact

1. Kill the Sidebar (if you're not using it)

2. Replace the Header Counter with a Light COUNT

3. Batch the Stock Checks

4. Keep the Price Indexers Warm

5. Paginate and Limit

6. Warm Up Product Images

7. Revisit Configurable-Product Items

A Note on Table Growth

6. Just use tuned: `throughput-performance`

Use `addAttributeToSelect` Explicitly