DEV Community: Magevanta

Magento 2 RabbitMQ Performance: Tuning Consumers and the Broker for High-Volume Stores

Magevanta — Thu, 10 Sep 2026 09:05:31 +0000

RabbitMQ is the invisible engine behind Magento 2's asynchronous work: bulk REST operations, async endpoints, order emails, product alerts, inventory reservation cleanup and B2B quote and shared-catalog updates all travel through message queues. The storefront can be perfectly fast while the queues silently back up — orders confirmed, but emails arriving an hour late, bulk operations stuck on "processing", and inventory_reservation rows growing because the cleanup consumer never caught up.

This guide is about the layer most performance audits skip: the broker and the consumers that drain it. You will learn how to read RabbitMQ's diagnostics, where the real bottlenecks hide (usually the consumers, sometimes the broker, rarely both), and a concrete tuning playbook that scales from a single node to a high-volume store.

How Magento uses RabbitMQ

Magento defines queues through three XML files per module: queue_topology.xml (exchanges, queues, bindings), queue_consumer.xml (which consumer processes which queue, with what handler) and communication.xml (which topic routes to which handler). Messages published under a topic land in the broker, and a consumer process picks them up, calls the handler, and acknowledges the message.

Everything is opt-in per queue: you can run consumers per queue yourself with bin/magento queue:consumers:start, and heavy modules (async order processing, B2B, inventory) add their own consumers. If a consumer is never started, its queue simply fills up. That is the most common "RabbitMQ problem" on real stores: not a broker issue, a missing or under-provisioned consumer. See the async operations and message queues overview for the full architecture.

Diagnose before you tune

Never guess where the backlog is. RabbitMQ ships everything you need on the node itself:

# Per-queue depth and consumer state — your primary view
rabbitmqctl list_queues name messages messages_ready messages_unacknowledged consumers

# Who is connected and how many channels they hold
rabbitmqctl list_connections name channel_max client_properties

# Per-consumer state: which queue, how many messages it holds
rabbitmqctl list_consumers

# Broker health: memory, disk, alarms, file descriptors
rabbitmq-diagnostics memory
rabbitmq-diagnostics alarms
rabbitmqctl status

On the Magento side, get the list of consumers and confirm which are actually running:

bin/magento queue:consumers:list
ps aux | grep queue:consumers

Read the numbers like this:

messages_ready high while consumers > 0: the handlers are too slow or there are too few consumers. Add workers or optimize the handler — more on both below.
messages_unacknowledged high: consumers are holding messages mid-processing, crashed mid-message, or stuck in a redelivery loop. Check consumer logs for repeated exceptions and look at handler duration.
Memory or disk alarm active: the broker is throttling publishers and consumers. Fix the broker first (see below); tuning consumers while the broker is in flow-control is pointless.
Consumers = 0 on a queue that should always be drained: the consumer died and nothing restarted it — a process-manager problem, not a tuning problem.

Also correlate with the database. A queue backlog usually shows up as side effects: inventory_reservation growth when the cleanup consumer lags (see the inventory reservation deep dive), or an exploding bulk/operation table when async.operations.all is stuck (see sales order performance).

Tune the consumers — the biggest win

1. Decide: wait or exit

By default a Magento consumer exits when the queue is empty or after --max-messages. Frequent exit/restart churns connections and delays message processing. Set consumers_wait_for_messages in app/etc/env.php so consumers stay alive and wait for new messages:

'queue' => [
    'consumers_wait_for_messages' => 1
],

2. Run more than one process per queue

A single consumer is usually single-threaded PHP. Throughput scales with worker count until you saturate the handler's real bottleneck (database writes, API calls, filesystem). Run several processes for the queues that matter:

bin/magento queue:consumers:start async.operations.all --max-messages=10000 &
bin/magento queue:consumers:start async.operations.all --max-messages=10000 &
bin/magento queue:consumers:start async.operations.all --max-messages=10000 &

For long-lived setups, declare parallelism in app/etc/env.php instead of juggling background processes:

'queue' => [
    'consumers_wait_for_messages' => 1,
    'consumers' => [
        'async.operations.all' => ['multiple_processes' => 3]
    ]
],

Magento 2.4.6+ goes further with declarative consumer settings in app/etc/consumers.xml, where you can cap runtime per process per consumer:

<config>
    <consumer name="async.operations.all"
              maxMessages="10000"
              maxExecutionTime="3600"
              maxIdleTime="60"
              multipleProcesses="3"/>
</config>

On the command line the same caps exist since 2.4.6 as --max-execution-time and --max-idle-time, next to the classic --max-messages and --batch-size. Pick your poison; the declarative file survives deploys and is reviewable, which is why we prefer it.

3. Cap messages per process — memory control

Queue consumers are long-running PHP, and long-running PHP accumulates memory: object managers, singletons and collection instances that never get released. A consumer that runs for days will quietly grow from 120 MB to a gigabyte before crashing — we covered the mechanics in memory leaks in cron jobs & queue consumers. The standard fix is the bounded worker: --max-messages (and --max-execution-time) so each process restarts before memory becomes a problem. 10000 messages or 3600 seconds per process is a sane starting point; watch RSS over a week and tighten until restarts cost less than the leaks.

4. Respect ordering and idempotency

Multiple consumers on one queue mean messages can be processed out of order and retried. Most Magento queues tolerate that (bulk operations, emails, reservations), but the handlers must be idempotent: a message redelivered after a crash (redelivered=true) must not double-apply. If you have a queue where order truly matters, run a single process for it and accept the throughput ceiling.

5. Stop poison-message loops

A handler that always throws (bad payload, missing product, persistent API error) gets the message rejected and redelivered forever — the consumer logs the same exception in a tight loop, hammering the broker and the database while messages_unacknowledged climbs. Two proven fixes: make the handler safe against bad input (validate, catch, log-and-skip), and add a dead-letter exchange in queue_topology.xml so repeated failures land in a quarantine queue you can inspect instead of looping.

Tune the broker

Right-size the node

RabbitMQ is memory- and I/O-hungry. Give it its own VM or container; do not share a disk with MySQL, and never let the broker swap. For high-volume stores, 4 GB+ RAM and SSDs are a floor, not a luxury — the load testing & capacity planning guide has a method for finding how much of this you actually need.

Memory watermark — the alarm everyone hits

The broker blocks publishers (flow control) when memory exceeds vm_memory_high_watermark, 0.4 (40% of RAM) by default. On a box with 8 GB that means flow control starts at 3.2 GB — which on stores with deep queues, many consumers and default channel buffers happens sooner than you think. Tune it deliberately, not as a knee-jerk:

# rabbitmq.conf
vm_memory_high_watermark.absolute = 6GB
disk_free_limit.absolute = 2GB

The same logic applies to disk: disk_free_limit defaults to 50 MB, which is far too little for a busy store — a full disk freezes everything. Set an absolute limit you can live with.

File descriptors and connection limits

Every consumer connection, channel and queued message can eat file descriptors. The classic failure is consumers that cannot reconnect because the broker hit its FD ceiling. Raise the system ulimit (65535 or higher) and verify with rabbitmqctl status — the File descriptor count/limit line. If your consumers each hold multiple channels, also check channel_max.

Heartbeats

RabbitMQ's default heartbeat is 60 seconds. Magento's AMQP client can run with heartbeat 0 (disabled), which means network equipment can silently kill idle consumer connections — the queue looks drained, the consumer looks alive, and nobody is doing any work. Configure heartbeat explicitly in the AMQP section of app/etc/env.php (for example 'heartbeat' => 60) and monitor list_connections for the timeout column so churn is visible.

Quorum queues for durability, classic for throughput

Magento's default topology uses classic queues, which are the fastest choice for a single-node broker. If you run RabbitMQ in a cluster, know that mirrored classic queues are deprecated and removed in RabbitMQ 4.0 — plan for quorum queues (RabbitMQ 3.8+), which replicate and can survive node loss. Quorum queues cost write amplification, so use them for the critical queues (order processing, B2B) and keep classic queues for throwaway work.

Run consumers properly in production

The consumers_runner cron job Magento ships is fine for keeping a low-volume store's consumers alive, but for anything serious use a process manager. systemd or supervisord gives you autostart, autorestart with proper backoff, startsecs crash detection, logging, and resource limits per consumer:

[program:magento_async_operations]
command=php /var/www/magento/bin/magento queue:consumers:start async.operations.all --max-messages=10000
user=www-data
autostart=true
autorestart=true
startsecs=10
numprocs=3
process_name=%(program_name)s_%(process_num)02d
redirect_stderr=true

Notes from real deployments:

Give consumers their own PHP-FPM pool settings equivalent — they compete with web traffic for CPU and MySQL. On a busy store, cap worker counts so a backlog drain doesn't starve the storefront; see PHP-FPM tuning for the same calculation applied to web workers.
When a backlog builds up (flash sale, failed consumer overnight), add temporary workers rather than restarting the broker. Draining a 200k-message queue is a throughput problem: workers, not magic.
Alert on what matters: queue depth and message age exceeding a threshold, messages_unacknowledged growth, memory/disk alarms, and consumers = 0 for critical queues. Every alert needs a runbook action, or it becomes noise you ignore.
Test under load before raising worker counts in production. Email sends and API calls have their own ceilings — blasting 10 workers at a slow SMTP relay makes the backlog worse, not better. The email performance guide shows the same pattern for outbound sending.

Playbook summary

Measure first: rabbitmqctl list_queues for ready/unacked depth, rabbitmq-diagnostics alarms, queue:consumers:list against ps aux.
Set consumers_wait_for_messages=1 so consumers stop exit/restart churn.
Scale consumers: multiple_processes per queue in env.php, or consumers.xml (2.4.6+) with maxMessages/maxExecutionTime/maxIdleTime.
Bound memory: --max-messages/--max-execution-time caps so processes restart before leaking.
Kill poison loops: validate and catch in handlers; dead-letter queue for repeated failures.
Right-size the broker: dedicated node, explicit vm_memory_high_watermark and disk_free_limit, raised file descriptors, configured heartbeats.
Run under a process manager with alerting on depth, age, unacked, alarms and zero-consumer states.
Test under load before scaling workers, and watch the downstream bottleneck (DB, SMTP, APIs), not just queue depth.

A healthy RabbitMQ setup is boring: queues near zero, consumers stable for weeks, no alarms. If yours is exciting, work through the diagnosis first — the backlog is almost always a consumer problem wearing a broker costume.

Magento 2 Memory Leaks in Cron Jobs & Queue Consumers: Find, Fix and Prevent Them

Magevanta — Wed, 09 Sep 2026 09:04:14 +0000

Cron jobs and queue consumers are the background engine of a Magento 2 store — and the most common place where memory problems hide. A web request lives for a second and dies, taking its garbage with it. A queue consumer or a heavy cron job can run for hours, and every leak it accumulates stays in the process until it crashes.

The typical story: the consumer worked fine on Monday. By Wednesday it has processed 40,000 messages, its RSS has climbed from 120 MB to 900 MB, and at 2 AM it slams into memory_limit and dies. Messages pile up, the email backlog grows, and the only clue in the logs is Allowed memory size of 262144000 bytes exhausted with a stack trace that points nowhere useful.

This guide explains why Magento leaks in long-running processes, how to prove it, and a fix playbook you can apply today.

Why PHP processes grow without bound

PHP is not inherently leak-prone for short requests. It frees memory by reference counting: when an object's refcount drops to zero, the memory is reclaimed immediately.

Three things break that model in long-running processes:

Circular references. Object A holds a reference to B, B holds one back to A. Neither ever reaches zero. PHP's cycle collector (gc_enable()) exists to break these, but it only helps if it actually runs, and Magento is full of cycles: product ↔ stock item, order ↔ order items, plugin proxies capturing their targets.
Static and singleton state. A web request dies and everything is freed. A consumer doesn't. Anything stored in a static property, a singleton, or the object manager lives until the process restarts. Magento 2 is built on the object manager and singletons, so a single line of extension code that stashes a collection "for later" becomes a permanent retention point.
Collection internals. Magento\Framework\Model\ResourceModel\Db\Collection\AbstractCollection keeps every loaded entity in both _items and _itemsById. If your loop loads 100,000 products into one collection, all 100,000 objects stay referenced until the collection is cleared or falls out of scope — which in a long-lived loop may be never.

The Magento-specific retention points

ObjectManager & singleton instances — the DI container keeps whatever it created, for the lifetime of the process.
Event dispatch — observers that capture objects into static arrays or into other long-lived objects.
Loggers and the profiler — see below, this one is easy to hit accidentally.
Message queue internals — consumer loops that keep the last message object (or an array of processed messages) referenced until the next iteration.
Caches with static backing — any "cache in a static array" pattern (common in third-party modules and cache warmers) grows one entry at a time, forever.

Detect it: measure RSS over time, not peak

A leak is a trend, so a single measurement proves nothing. You need a time series:

# Watch a running consumer's memory grow (or not)
CONSUMER_PID=$(pgrep -f "queue:consumers:start" | head -1)
while true; do
  ps -o pid,rss,vsz,etime,cmd -p "$CONSUMER_PID"
  sleep 10
done

For cron runs, add a memory checkpoint at the end of your own jobs:

$this->logger->info(sprintf(
    'Job %s done: peak=%dMB, end=%dMB',
    $jobName,
    memory_get_peak_usage(true) / 1048576,
    memory_get_usage(true) / 1048576
));

Getting the trend lets you classify the shape:

Stable plateau, then a step up — an event-based retention (e.g. every N messages something is cached).
Linear climb — a per-iteration leak; each message or row retains a fixed amount.
Sawtooth but drifting upward — the cycle collector runs and reclaims, but retention outpaces it.
Peak-only tools lie — /usr/bin/time -v shows peak RSS for the whole run, which for a well-behaved job is high anyway. For leak hunting, profile over time with Blackfire or xhprof memory graphs, or sample RSS as above.

The classic leak scenarios on real stores

1. Consumers running forever. bin/magento queue:consumers:start <name> without --max-messages runs until killed. Every per-message retention compounds hour after hour. This is the single most common cause of consumer OOMs. Restart them on a schedule (see the playbook).

2. The profiler left on. If dev/debug/profiler is enabled (or a profiler module is active), Magento\Framework\Profiler accumulates timing data for every event, timer, and query in memory. In a long-running process this alone can add hundreds of MB. It's a dev tool — keep it off in production, and never enable it on a consumer that you don't plan to restart.

3. Whole-collection loops. Loading a full collection and iterating it is fine in a web request, lethal in a cron job:

// Bad: every product stays referenced in the collection
$products = $this->productCollectionFactory->create();
$products->addAttributeToSelect('*'); // full EAV rows
foreach ($products as $product) {
    $this->doSomething($product);
}

4. Import scripts that slurp files. file($csvPath) on a 500 MB export and $product->load($sku) per row without clearing — peak memory explodes and nothing gets reclaimed between rows.

5. Indexer or scheduler plugins. Reindex processes already batch internally in 2.4.x, but extensions hooked onto indexer events (catalog permissions, staging, custom price dimensions) often retain per-batch data in static arrays. Profile the reindex with xhprof and look at who holds references after each batch.

The fix playbook

1. Bound every long-running process

For consumers, never rely on "it's been fine for months":

bin/magento queue:consumers:start order_emails --max-messages=500

--max-messages exists since Magento 2.3 and cleanly exits after N messages; recent 2.4 releases also support --max-execution-time. Pair this with a process supervisor (Supervisor, systemd, or the cron_consumers_runner config) that respawns the consumer immediately — then a bounded restart is invisible to your queue. This turns "memory climbs forever" into "memory climbs for 500 messages, then a fresh process starts".

2. Batch and clear collections

$collection = $this->productCollectionFactory->create();
$collection->addAttributeToSelect('*');
$collection->setPageSize(500);
$lastPage = $collection->getLastPageNumber();

for ($page = 1; $page <= $lastPage; $page++) {
    $collection->setCurPage($page);
    foreach ($collection as $product) {
        $this->doSomething($product);
    }
    $collection->clear(); // release _items and _itemsById
}

->clear() is the key line: it drops the internal item arrays so the next batch starts from a clean slate.

3. Unset and collect cycles in custom loops

$processed = 0;
while ($message = $queue->receive()) {
    $this->process($message);
    unset($message);
    if (++$processed % 100 === 0) {
        gc_collect_cycles(); // break circular references now
    }
}

Calling gc_collect_cycles() periodically is cheap insurance in any long-running loop; it lets the cycle collector sweep instead of letting garbage accumulate until the process dies.

4. Ban static retention in custom code

Review your own modules and the offenders from a third-party extension performance audit: replace "static array as cache" with a real cache backend, and never store loaded entities in static properties across iterations. If you genuinely need to reference an object without keeping it alive, PHP 7.4+ WeakReference is the correct tool — but the correct answer is usually "don't retain it at all".

5. Prefer more, shorter workers over one immortal worker

A consumer that runs 24/7 with 2 GB of retained memory is a crash waiting to happen. Five consumers with --max-messages=200 under Supervisor process the same volume, spread risk, and absorb a crash without a backlog. The same logic applies to cron: split heavy jobs into smaller scheduled runs instead of one monolithic window (see the cron optimization guide).

6. Monitor memory as a first-class metric

Sample RSS per process with Prometheus + node_exporter (or your APM), and alert on trend over 1–2 hours, not on absolute thresholds. If a consumer's RSS climbs steadily, that's a leak signal long before it OOMs. Keep an eye on the number of consumers vs memory_limit on the box: with several consumers at 1 GB each, a 4 GB server dies from memory pressure even though no single process crashed.

7. Don't just raise memory_limit

Raising memory_limit converts a 30-minute crash into a 3-hour one, and pushes the problem into the kernel: under sustained pressure the OOM killer may take down MySQL or Redis along with your consumers. Fix the leak or bound the process — the limit is a safety net, not a solution.

Verify the fix

Run the consumer on a baseline, sample RSS every few minutes, and compare before/after:

Before: RSS climbs ~25 MB per 1,000 messages and never comes back down.
After: RSS plateaus or sawtooths within a ±50 MB band over 20,000 messages.

If the trend stays flat over a full day and a bounded restart cycle, the leak is contained. Log memory_get_peak_usage(true) at the end of every cron job so a regression shows up in your logging best practices trail before it shows up in an incident.

Quick checklist

Every queue consumer started with --max-messages (or --max-execution-time) and under a respawning supervisor.
Cron jobs batch-load collections and call ->clear() per batch.
No static arrays holding entities across loop iterations; no file() on huge CSVs; streaming imports instead.
Profiler disabled in production.
Custom long loops call gc_collect_cycles() periodically.
RSS trend monitored and alerted, not just peak memory.
memory_limit treated as a safety net, not a fix.

Memory leaks in cron and queue consumers are an operational problem, not a mystery: measure the trend, bound the process, batch the work, and restart on a schedule. Do that, and the 2 AM OOM becomes a thing of the past — and your message queues and indexers keep running while you sleep.

Magento 2 Customer Login & Authentication Performance: The Slow Login Bottleneck

Magevanta — Tue, 08 Sep 2026 09:01:09 +0000

A slow login is one of the most damaging performance problems a store can have. Unlike a slow category page, which costs you a view, a slow login sits directly between a returning customer and their wallet. Every extra second on the authentication path quietly raises cart abandonment and pushes people toward guest checkout or a competitor.

The frustration is that login slowness rarely shows up in your standard page-speed metrics. A login POST is a form submission, not a render — so Core Web Vitals tells you nothing. You have to measure the request itself and understand the work Magento does between "submit" and "redirect to account". This guide breaks down every step and what you can safely optimize.

What actually happens during a login request

When a customer submits the login form, Magento runs a surprising amount of work in a single request:

The POST hits the front controller and session cookie handling.
The account controller loads the customer via CustomerRepositoryInterface and verifies the password.
Magento validates the password hash with PHP's password_verify.
It reloads the full customer object and all dependent data (addresses, groups, default billing/shipping, tax + exchange-rate data).
Customer data sections are refreshed so the quote, customer and cart sections repopulate.
The session is persisted (or the token exchanged if you use a custom auth flow).
The account dashboard or redirect target renders.

Each step has its own cost, and most of them multiply.

The real cost of password hashing

Magento 2 stores customer passwords with PHP's password_hash/password_verify using bcrypt. This is the right call for security, but bcrypt is deliberately expensive — it is designed to slow down brute-force attacks. The default cost factor in Magento's Security.xml is 10, meaning roughly 2^10 iterations of the key-derivation rounds.

A bcrypt verify at cost 10 typically takes 50–150 ms of pure CPU on a modern server, and far more on constrained or shared hosting. That doesn't sound like much until you add it to everything else.

The trap people fall into is cranking the cost factor up "for security." Every increase in cost roughly doubles the time. Going from cost 10 to 12 can push a single verify past 200–400 ms of CPU — on every login, for every customer, multiplied by your login rate. If you also run brute-force two-factor flows or admin logins through the same hashing, the cost stacks.

Verify the cost, don't guess

You can check the configured cost factor in app/etc/env.php or the Security config:

$hash = $customer->getPasswordHash();
echo password_get_info($hash)['options']['cost'];

If the cost is 12 or higher and logins feel heavy, do not lower it blindly — lower cost directly weakens security. Instead, understand whether you actually need that high a factor. NIST and most providers consider 10–11 acceptable for customer-facing bcrypt in 2026; anything above that gives marginal security gain against password-cracking hardware already hitting diminishing returns, while costing you real latency per login.

There is a legitimate middle path: keep an adequate cost factor and move authentication off the main web thread via a queued or sub-request hashing flow. Magento's own CustomerAuthenticationInterface can be wrapped so verification runs asynchronously, or behind a pre-auth gate.

The N+1 problem in "load customer for login"

The biggest silent killer is how the customer is loaded after verification. CustomerRepositoryInterface::getById looks clean, but underneath it triggers attribute loading (EAV), plus selection of the default shipping address, billing address, and the customer group — often as separate queries. On a store with many attributes or a bloated customer_entity EAV layout, the post-login load can fire dozens of queries.

Compounding it: tax and exchange-rate data are resolved per customer group on every login, and the account page then queries order history, wishlist counts and newsletter state. None of this is cached.

What to do

Profile first: enable the built-in profiler or log query counts around the login request. If you see more than ~20 queries in CustomerRepository::getById territory, you have a real EAV problem.
Trim customer attributes: move rarely-used custom customer attributes that aren't indexed for login out of the direct-load path. Every extra attribute added to the customer form adds EAV rows and join cost on every load.
Batch the dependent data: wrap the default address, group and tax lookups in a single getList with appropriate attribute sets instead of separate repository calls.
Cache what's stable: customer group, default address and tax-class data change rarely. A short-lived cache or layered cache handler around those lookups removes the per-login query spike without risking stale pricing.

Session persistence: the silent second bottleneck

After auth, Magento persists the customer session. Where you store sessions already got a full write-up elsewhere on this site (Redis over files, every time). But login adds extra session weight: the auth flow writes the customer ID, form keys, the cart contents reference, and section data. If your session store is disk-backed or your single Redis node is undersized, that write lands smack in the middle of the login request.

Check your session store is also scanned on read: the first thing login does is read the existing guest session to merge the cart. A slow session read (or a full-GC pass scanning disk) makes every login crawl.

Customer data sections get refreshed on login

When a customer logs in, the frontend reloads all customer data sections (customer, cart, messages, and any custom section you registered) via customerData.reload(). Each section is a separate AJAX request hitting the account controller endpoints. If you see a burst of parallel /customer/section/load calls after the redirect, that's normal — but it's also fresh DB/Redis work that can be trimmed by disabling sections you don't use (see the customer-data-sections strategy on this site).

Bruteforce protection & external auth — measure it

Magento 2.4's brute-force protection (login attempt limits and CAPTCHA/reCAPTCHA) is good, but the throttling lookup and reCAPTCHA verification add latency. If you use Magento\LoginAsCustomer-style proxying, SAML, or LDAP auth, each login now depends on an external round-trip — often 200–600 ms of network time on top of everything above.

For external auth, add connection pooling and keep the identity provider endpoint hot (a cold IdP call can add a full second). At minimum, put a caching layer on the session-bound auth token so repeated requests within a session don't re-hit the IdP.

The optimization playbook

Measure the login endpoint directly — cap a POST login in Browser DevTools network tab or curl -w "%{time_total}" with a valid credential. Get a before number.
Enable the profiler and count queries for one login. Fix any EAV/dependent-data N+1 first — this is usually the biggest win.
Check the bcrypt cost factor and confirm it's 10–11, not inflated.
Move sessions to Redis (or upgrade the node) and confirm the store is healthy on read.
Trim customer data sections that reload on login.
Pool and cache external auth if you use SSO/LDAP/SAML.
Add the login path to your performance regression budget (Lighthouse CI or a curl TTFB gate) so a future plugin can't silently re-slow it.

When to leave it alone

Don't shave security to hit a number. Keep the bcrypt factor adequate, keep brute-force throttling on, and don't cache anything customer-specific or price-sensitive. The goal is to remove wasted work — duplicate queries, avoidable EAV joins, cold session stores, redundant external calls — not to weaken the auth itself. Do that, and a login that once took 1.5 s of accumulated work can drop to a few hundred milliseconds of necessary work, which is exactly what a returning customer should feel.

Performance TPU: profile the login POST end-to-end, then attack the N+1 and session-store costs before ever touching the hash cost.

Magento 2 Sitemap Generation Performance: Why It Spikes CPU, Memory and MySQL

Magevanta — Sat, 05 Sep 2026 09:02:00 +0000

Sitemap generation is one of those background jobs everyone ignores — until the sitemap cron starts pegging CPU and memory on a large catalog at midnight, collides with the price indexer, and makes the store crawl. The XML sitemap is tiny compared to your catalog, but the process that builds it walks your entire product, category and CMS content, so its cost scales linearly with catalog size. This guide explains exactly how Magento builds the sitemap, where the hidden cost comes from, and how to make generation fast, batched and off-peak.

How Magento builds the sitemap

Behind the scenes, Magento runs the sitemap_generate cron job, which is registered in Magento\Sitemap\etc\crontab.xml at the default schedule of 0 0 2 1 * — i.e. at 2 AM on the first of January by default. Most production setups override this in env.php or the admin (Stores > Configuration > Catalog > XML Sitemap) to run nightly or weekly. When it fires, the Sitemap model calls:

Sitemap::generateXml() which collects products, categories and CMS pages per configured store view and renders each entry as a <url> node
It resolves each entity's final URL via the URL rewrite table (url_rewrite), computes priority and change frequency from admin config, and optionally appends image URLs configured on products (images under sitemap settings)
It writes the resulting XML to pub/media/sitemap/sitemap.xml (one file per store view)

The observable cost looks cheap: a few seconds, a few megabytes of XML. The real cost is internal.

Where the hidden cost comes from

1. Whole-catalog iteration on every run

Sitemap generation is not incremental. Every scheduled run walks every product, every category and every CMS page again, even if nothing changed. On a 100k-SKU catalog that is tens of thousands of entities each run, regardless of whether a single page changed since the last sitemap.

2. Per-entity URL and attribute resolution

Each product entry needs its final store_id-scoped URL, so the generator joins against url_rewrite and reads core EAV attributes for the entity. Naive versions of this pattern perform several queries per entity — a classic N+1. Newer Magento releases (2.4.x, especially 2.4.7+) batch entity resolution via SitemapItemResolver and getCollection() with chunked iteration, which is dramatically cheaper than the older per-entity resource models. If you are on 2.4.6 or older, part of your sitemap slowness is simply the un-batched resolver.

3. Whole-XML-in-memory

generateXml() builds the complete XML document in memory before writing it to disk. On a very large catalog the sitemap can reach tens of megabytes, so peak memory on the CLI worker spikes proportionally to catalog size. And because this runs on the same cron consumer pool, a memory-hungry sitemap run can tip a PHP worker over memory_limit and abort mid-generation, leaving a truncated sitemap on disk.

4. MySQL load on a full-table scan

Reading every product and rewriting it joins the catalog tables, url_rewrite, and the media gallery. On stores with heavy url_rewrite tables (the URL rewrite performance area), the sitemap cron can trigger a costly scan right when your nightly cron optimization and indexer jobs are also running — three heavy jobs competing for the same pool.

Diagnosing a slow sitemap run

Get a baseline before changing anything:

# Time a single generation run
time bin/magento sitemap:generate

# Watch real peak memory (set -d for the run only, keep the pool default)
/usr/bin/time -v php -d memory_limit=2G bin/magento sitemap:generate

Also record:

The size and line count of pub/media/sitemap/sitemap.xml — compare across stores
sitemap.log under var/log/ — by default Magento logs generation progress
The MySQL query time during the run (SHOW FULL PROCESSLIST or your slow-query log) to catch full scans on url_rewrite or catalog_product_entity
Whether the run is killed or times out — that is a truncated sitemap, not a completed one

If the run is crash-safe, quick, but still late at night colliding with other jobs, the fix is scheduling, not code.

The optimization playbook

1. Batch: upgrade your resolver

If you are on Magento 2.4.5/2.4.6, the single cheapest win is upgrading to a release with the batched SitemapItemResolver. It replaces per-entity queries with chunked collection iteration and cuts both runtime and query count by an order of magnitude on large catalogs. Measure before and after — this is the highest-ROI step.

2. Offset generation per store

The sitemap generates one file per store view. If you run multiple store views (see multistore performance), spread them instead of generating all simultaneously. You can trigger per-store generation programmatically with --store on bin/magento sitemap:generate, then schedule each store on a different time slot so no single cron window runs all stores at once.

3. Move it off the main cron window

Sitemap does not need to run alongside the price indexer or full reindex. Move it to a low-traffic, low-contention window — ideally a separate schedule from the admin cron group that runs indexers. A dedicated cron schedule (config:crontab:set wget "https://..." or a separate consumer) keeps sitemap out of the main cron pileup.

4. Shrink what gets included

Fewer entries means a smaller file and less work:

Disable sitemap for store views you do not need (Stores > Configuration > Catalog > XML Sitemap > Enabled, per scope)
Exclude entities that should not be indexed
If product image URLs are enabled, they multiply XML size and add media-gallery joins — disable them unless your SEO setup needs rich results
Keep url_rewrite clean and pruned; the sitemap reads it per entity, so orphaned rewrites make every scan slower (see the URL rewrite deep-dive)

5. Stream instead of buffer (large catalogs only)

If you are on an older version and a very large catalog, the in-memory generateXml() is the bottleneck. Replace the default model with a custom generator that iterates the collection in chunks and writes directly to a temp file, then renames it into place at the end. Chunked file writes keep peak memory flat and guarantee the live sitemap is never a truncated one. This is a small custom module and is the correct fix rather than raising memory_limit on the pool.

6. Serve it smartly

Share-cached sitemaps are served as static files from pub/media. Make sure the path is served by your web server directly (not routed through PHP-FPM) so the CDN and Varnish cache it, and confirm robots.txt points at the correct store-scoped file. If you route the sitemap through an HTTP handler, you can also delegate generation to a lightweight background request instead of the cron worker.

Monitoring

Add sitemap generation to your automated regression testing budget: assert that bin/magento sitemap:generate on your staging catalog (or a sized-down clone) completes under a budgeted wall-clock time and stays under a memory ceiling. A regression — e.g. a third-party module that hooks sitemap generation and triples its runtime — should fail CI, not silently slow your nightly job.

Summary

Sitemap generation looks trivial but walks your whole catalog on every run. The three levers that matter: use a batched resolver (upgrade for large catalogs), schedule it off-peak and per-store so it never collides with indexers, and shrink or stream the output so memory stays flat. With that, a midnight sitemap cron is a blip, not a spike.

Magento 2 Frontend Performance: Web Fonts, Critical CSS and Render-Blocking Resources

Magevanta — Fri, 04 Sep 2026 09:01:28 +0000

A Magento 2 frontend can have excellent backend TTFB and still feel slow, because the browser spends its first seconds downloading and blocking on stylesheets and fonts before it can paint a stable page. Web fonts and render-blocking CSS are where the Core Web Vitals metrics you spent weeks on — especially Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) and First Contentful Paint (FCP) — get silently undermined. This guide walks through how a Magento theme loads these resources by default and how to reclaim that frontend time methodically.

Why fonts and CSS dominate the critical path

For an anonymous visitor hitting a default Luma-based or Hyva-style theme, the browser must fetch, parse and apply the full stylesheet before it can render. Even with aggressive JavaScript bundling, an unoptimized theme ships one large styles.css plus a handful of web font files — several hundred kilobytes of blocking work before first paint. Fonts add a second tax: browsers default to font-display: auto, which hides text while a web font downloads (FOIT, flash of invisible text) and shifts layout when it eventually swaps in.

The critical rendering path for a typical page is: HTML → CSSOM (blocking stylesheets) → layout → paint. Every byte of CSS on this path delays FCP; every web font that isn't preloaded delays the visible headline, which is often the LCP element. The fix is not "don't use fonts" — it is controlling when each resource loads and how much ships.

Where Magento loads frontend resources

Understand the two rails, because they behave differently:

CSS is usually combined and deployed by setup:static-content:deploy and linked in <head> by Magento_Theme. Magento emits it via Magento\Framework\View\Asset\Repository, and themes override layout handles (default_head_blocks) to inject stylesheets. Because they are plain <link rel="stylesheet"> tags, every one of them blocks render.
Web fonts are loaded either from the theme's fonts folder, from a CDN like Google Fonts / Font Awesome, or — in Magento UI / older themes — via Magento\Theme\Block\Html\Head with css/ resources. The classic Luma setup links a fonts.css in the head, which pulls in the actual @font-face files.

The first audit is simply to view-source your rendered homepage and count <link rel="stylesheet"> entries and font requests, then use the Performance panel's blocking list in DevTools. Stores frequently discover 8–20 stylesheets and 6–12 font files they believed were merged or subsetted.

Practical levers, in order of payoff

1. Cut the payload before you optimize delivery

The cheapest optimization is shipping less. If a theme imports multiple font families as full weights and styles, prune to what actually appears in your templates. Each family at 2–3 weights with latin subset typically costs 30–80 KB per file. Remove unused Google Fonts families and Font Awesome glyph packs you load wholesale; replace them with only the icons you render.

For Magento-deployed assets, keep the merged stylesheet coherent: setup:static-content:deploy with -j parallelism and the optimized strategy (see the static content deploy guide) shortens build, but the browser still downloads one combined CSS. Splitting a megabyte block into a small "critical" file and a deferred "rest" file is the classic critical-CSS play.

2. Critical CSS + deferring the rest

Extract the styles that govern above-the-fold content (header, hero, first product tiles) into a small inline <style> in <head>, then load the full stylesheet asynchronously or after load. Two ways to load the non-critical sheet without blocking:

<!-- load after paint -->
<link rel="stylesheet" href=".../styles.css" media="print" onload="this.media='all'">
<!-- or -->
<link rel="preload" href=".../styles.css" as="style" onload="this.rel='stylesheet'">

Pair this with a noscript fallback. In a Magento theme, inject the critical CSS through a child theme's Magento_Theme/layout/default_head_blocks.xml:

<referenceBlock name="head.additional">
    <block class="Magento\Framework\View\Element\Template"
           name="critical.css"
           template="Magento_Theme::critical-css.phtml"/>
</referenceBlock>

where that template <?= $criticalCss ?> is the extracted above-the-fold styles. Generating the extract is a build step — tools like critical, or penthouse for full HTML pages, produce the inlined block; run it in CI after static:content:deploy so it tracks theme changes rather than drifting.

3. Font loading: subset, format, preload, and display

Web fonts have four knobs. Set all of them:

font-display: use swap (or optional for icon-ish UI fonts) so text renders in a fallback instantly and swaps when ready. This removes FOIT and most of the font-related CLS. In your @font-face blocks, this is one line per face; Google Fonts lets you append &display=swap.
Subset: serve only the character ranges a store actually uses. Tools like glyphhanger or Font Squirrel's subsetter slice the .woff2 to Latin (and any accented locales) — often cutting file size 60–80%.
Format: ship only woff2 (universally supported now) instead of carrying woff/ttf/eot fallbacks. Each extra format is just extra bytes the browser ignores.
Preload the hero font: if the headline font renders the LCP text, <link rel="preload" href="/fonts/headline.woff2" as="font" type="font/woff2" crossorigin> lets the browser start that download during HTML parse instead of only after it hits the stylesheet. This is frequently the difference between a 0.8s and a 1.6s LCP.

A Magento child theme declares fonts via the <head> block. For the standard @font-face loading, overriding the theme's fonts.css with a leaner, woff2-only, subsetted version is the fastest route, then preload the single face that matters:

<referenceBlock name="head.additional">
    <block class="Magento\Framework\View\Element\Template"
           name="preload.font" template="Magento_Theme::preload-font.phtml">
        <arguments>
            <argument name="fontUrl" xsi:type="string">/fonts/headline.woff2</argument>
        </arguments>
    </block>
</referenceBlock>

4. Resource hints and eliminating round trips

preconnect: for Google Fonts / CDNs, <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin> and <link rel="preconnect" href="https://cdn.example.com"> tear down the connection early, shaving 1–2 RTTs off those requests.
preload as="style" for the single most important stylesheet or image so it joins the early download.
Keep defer/async on non-critical JavaScript. A dataLayer or analytics script without defer delays interactive; the JavaScript bundling and RequireJS guide covers that side in depth.

Measuring the result

Before/after matters more than any rule of thumb. Use Lighthouse on a representative product page, and capture FCP, LCP, CLS, and total blocking time. Then confirm in the DevTools waterfall that the critical CSS is inlined, the main stylesheet is non-blocking, and the hero font request starts preload-time and arrives before first paint. Validate the font swap with a throttled 4G profile: text should be legible (fallback) immediately, not blank.

For automating this as a guard rail, fold FCP/LCP/CLS budgets into your pipeline — the automated performance regression testing guide shows how to make these thresholds fail CI rather than silently regress.

A sane baseline checklist

[ ] Few, merged, woff2-only web fonts; unused families and glyph packs removed
[ ] font-display: swap (or optional) on every @font-face
[ ] Hero LCP font preloaded with crossorigin
[ ] Critical CSS inlined; full stylesheet loaded non-blocking with noscript fallback
[ ] preconnect to CDN/font origins
[ ] Non-critical JS defer/async; no render-blocking third-party scripts in <head>
[ ] FCP/LCP/CLS measured before and after, ideally in CI

When to skip this

If a store is still serving a slow, un-merged stylesheet or lacks HTTP/2 entirely, fix those first — see the CDN configuration guide and the nginx optimization guide. Critical CSS and font preload are refinements that amplify a solid delivery pipeline; applied to a store with 1.5s of blocking CSS, they still help, but they are not a substitute for correct caching and a working reverse proxy.

Done right, web fonts and critical CSS turn a store that "paints late and shifts when fonts land" into one whose hero image and headline render in the first paint and stay put — which is exactly what LCP and CLS are asking for.

Magento 2 Time-to-First-Byte: Diagnosing and Cutting TTFB on Slow Stores

Magevanta — Thu, 03 Sep 2026 09:02:08 +0000

Time-to-First-Byte (TTFB) is the time between a browser sending a request and receiving the first byte of the response. In Magento 2 stores it is routinely the single biggest component of perceived slowness — and the part developers most often misread as a "network" problem. This is a measured, layer-by-layer guide to finding where your TTFB actually goes and reducing it.

Why TTFB matters more than you think

Lighthouse and Core Web Vitals shine a spotlight on Largest Contentful Paint (LCP), but LCP can rarely beat TTFB by much. A 1.2-second TTFB on a product page caps your LCP regardless of how aggressively you bundle JavaScript or serve compressed images. Google has measured that a 100ms reduction in TTFB reliably improves conversion, so it is worth treating TTFB as a first-class metric, not a side effect.

Before optimizing, log TTFB accurately. The Chrome DevTools Networking panel reports it, but for repeatable numbers use a scripted check that curls the page across several runs, warm and cold:

for i in 1 2 3 4 5; do
  curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s | Total: %{time_total}s\n" \
    https://example.com/product.html
done

The gap between TTFB and total time is download time (dominated by payload size, static assets, and compression). The gap between connection time and TTFB is server-side latency — that is what this article tackles.

Break TTFB into its layers

TTFB decomposes roughly as: DNS → TLS handshake → reverse-proxy accept → PHP-FPM queue/wait → PHP frame (router, bootstrap, layout, FPC/BFC hit) → database/Redis/Elasticsearch calls → first byte out.

Profiler output is the fastest way to see the split. The built-in Magento profiler (Mage::setIsDeveloperMode(true) plus dev/debug/profiler in the DB) prints a flat/grouped profile to the page. For production, an APM like New Relic or Blackfire shows the same breakdown without giving customers profiler output. If TTFB is high but the PHP profile is clean and fast, your latency is upstream — TLS, proxy, or queueing.

1. TLS and connection setup

Each HTTPS request pays for a TLS handshake. Two quick wins:

Enable TLS 1.3 and session resumption. TLS 1.3 cuts the handshake to one round trip and, with session tickets, allows resumption on subsequent connections. Make sure session_tickets and OCSP stapling are enabled at Nginx level.
Keep connections alive. keepalive 64; in the upstream block and HTTP/2 both let one browser connection serve many requests, amortizing handshakes across JS, CSS and image requests. A store that does this can drop its median TTFB noticeably on repeat visits without touching PHP at all.

2. Reverse proxy and PHP-FPM queueing

A very common failure is not a slow PHP process but PHP-FPM having no free worker to serve the request. Check the queue:

watch -n 2 "pgrep -c php-fpm"
# and inspect the Nginx error log for "max_children reached"

If you see the slow log filling (configure request_slowlog_timeout and slowlog in php-fpm.conf), workers are busy long past their budget. The remedy is usually pm.max_children too low for the traffic mix, or a handful of pathological requests monopolizing workers. Raising max_children without checking memory (pm is dynamic, each child consumes its memory_limit) can swap instead of speeding up.

Two structural fixes for queue health:

Health checks and drain. Route health-checked traffic to Nginx upstreams so dead or saturated FPM pools don't get new requests.
Microcache or Varnish in front. A reverse proxy that serves cached pages without touching PHP-FPM is the single biggest TTFB lever for anonymous traffic. The Full Page Cache deep dive explains why most product pages should be served entirely from cache, bypassing PHP and database on hit.

3. PHP frame and bootstrap

On a cache-miss (or for logged-in customers, who usually bypass FPC per-section), TTFB is dominated by the PHP bootstrap and layout rendering. Biggest contributors, in order:

Collection and EAV queries. Add the query list in the profiler; a handful of heavy collections on category/product pages often account for most of the DB time. The database index strategy guide shows how to find the offenders with EXPLAIN.
OPcache efficiency. Ensure opcache.enable=1, opcache.validate_timestamps=0 in production and a generous opcache.memory_consumption. The PHP OPcache tuning guide covers sizing.
Layout and blocks. Rendering dozens of blocks is cheap only if their data is cached (blocks, layout cache, translations). The UI component guide and customer data sections guide reduce per-request work for logged-in traffic.

4. Database and Redis/OpenSearch round trips

Cold product/category pages typically issue many backend calls. TTFB contributions here are really query latency times query count. Attack both:

Reduce query count — avoid N+1 collections, load relations in bulk (addAttributeToSelect in one pass rather than per-entity loops), and prefetch product options/stock in a single query.
Reduce per-query latency — correct indexes, warm buffer pool, and LOCAL cache for session/config. The MySQL read/write replication split moves the read load off the primary and can shave tens of milliseconds per request.

OpenSearch/Elasticsearch appears on search and layered-navigation requests. Watch slowlog in the cluster; facet-heavy queries can add hundreds of milliseconds to the category request that runs them.

Warm vs cold TTFB — track both

Cold TTFB (a page no one has requested lately) is dominated by cache-miss work and fills around best with a generous FPC. Warm TTFB (a page already in Varnish/Redis) tests your proxy, connection and FPC-hit path. A healthy store should show warm TTFB in the tens of milliseconds and cold TTFB under roughly 400–600ms on the product path; anything above that on warm hits usually points at a proxy misconfig or a broken cache-tag invalidation that is recreating pages constantly. The cache tag invalidation guide is the reference when pages never stay warm.

A practical reduction playbook

Measure first: scripted curls, warm and cold, plus an APM profile of the slowest URL.
Fix the queue: max_children, slow-log, and health checks before touching PHP code.
Serve from cache: ensure Varnish/FPC covers product and category pages for anonymous traffic.
Cut query count on the uncached paths (login, cart, customer account).
Verify TLS/HTTP2/keepalive so connection setup is not adding hundreds of milliseconds on repeat visits.
Re-measure after each change; a single metric (median warm TTFB) kept in CI with a budget prevents regressions, as described in automated performance regression testing.

TTFB is the one number that makes all your other front-end work pay off. Get it under control first — every subsequent optimization (bundling, image sizing, lazy loading) shows a bigger effect on a fast first byte.

Magento 2 PDF Generation Performance: Why Invoice PDFs Are Slow & Memory-Hungry

Magevanta — Mon, 31 Aug 2026 17:09:39 +0000

Click "Print" on an order and the browser sits there. Five seconds, ten seconds, sometimes a 504 from PHP-FPM — and on a big order, a memory spike that takes the admin pool down with it. Sales PDFs are one of the most quietly ignored performance problems in Magento 2: they're generated on every request, in pure PHP, with no cache, and the cost scales with the number of line items. This article shows exactly where that time goes, how to confirm it on your own store, and a practical playbook to make PDF generation fast — or get it out of the request path entirely.

Why PDF Generation Is Expensive by Default

When you print an invoice, packing slip, credit memo or order confirmation, Magento does not render HTML and convert it. It draws the PDF programmatically, page by page, using Zend_Pdf — the PDF engine from the Zend Framework 1 era that Magento still ships (via the magento/zendframework1 package). The classes that do the work live in Magento\Sales\Model\Order\Pdf:

AbstractPdf — the base class that lays out pages, draws the header, footer, logo and table scaffolding;
Invoice, Shipment, Creditmemo, Order — each implements the item-by-item drawing for its document type.

The drawing loop is the hot path. For every line item, AbstractPdf measures the rendered text width with _getTextWidth(), which calls into the font object's widthForString() — per character, in PHP. Then Zend_Pdf_Page::drawText() places every string at its coordinates, wrapping lines to fit the column. Add a logo image, a translated address block, item options, SKUs, tax rows, and a footer on every page, and a single invoice for an order with 100 line items easily takes 1–5 seconds of pure CPU and 5–20 MB of memory per document — all inside the PHP-FPM worker that is also serving your admin.

The kicker: none of it is cached. Every print request calls getPdf() again, re-measures every glyph, re-draws every page, and re-renders the whole document from scratch — even if nothing about the order changed since the last print.

Where the Time Actually Goes

Profile a PDF request with Blackfire, Xdebug or a simple microtime around getPdf(), and the wall-clock time concentrates in three places:

Text measurement and drawing. Zend_Pdf_Font::widthForString() and Zend_Pdf_Page::drawText() dominate. The cost is linear in the number of characters, so an order with 300 line items costs roughly three times what 100 items cost — plus the extra pages.
Document assembly in memory. Zend_Pdf keeps every page object and its full content stream in memory until render() flattens the document. A 50-page PDF is one big PHP object graph, and Zend_Pdf::render() then serializes fonts and content streams — a second CPU spike right before the download starts.
Batch multiplication. The admin "Print" action on the Sales > Orders grid (Magento\Sales\Controller\Adminhtml\Order\Pdf) loops over every selected order in a single request, concatenating all pages into one giant PDF before sending it. Select 100 orders with 40 items each and you're generating a 4000-line-item document synchronously. This is the classic 502 / 504 / memory-limit killer.

There's also a frontend angle: customers can print their own order PDF from the account area, so a malicious or curious user can trigger expensive generation on the storefront, where the FPC does nothing for you — a downloaded PDF is dynamic by nature.

How to Diagnose It on Your Store

Before changing anything, measure:

// pdf-bench.php - time one invoice PDF from the CLI
require BP . '/app/bootstrap.php';
$bootstrap = \Magento\Framework\App\Bootstrap::create(BP, $_SERVER);
$objectManager = $bootstrap->getObjectManager();
$invoice = $objectManager->create(\Magento\Sales\Model\Order\Invoice::class)->load(10012345);
$start = microtime(true);
$pdf = $objectManager->create(\Magento\Sales\Model\Order\Pdf\Invoice::class)->getPdf([$invoice]);
printf("time: %.2fs, peak memory: %.1f MB\n", microtime(true) - $start, memory_get_peak_usage(true) / 1048576);

In practice the fastest route is profiling one print request with Blackfire or Xdebug: look for Zend_Pdf_Page::drawText and Zend_Pdf_Font::widthForString in the hot methods list, and note memory_get_peak_usage() at the end. Then scale the test: generate PDFs for orders with 10, 50 and 200 line items and plot time and memory against item count. If the curve is cleanly linear, you're textbook Zend_Pdf; if it's worse, check for a custom module or extension that adds per-item drawing work (extra columns, barcodes, images) — third-party invoice extensions frequently add the most expensive drawing of all.

The Playbook: Batch, Cache, Replace

1. Get batch printing out of the request path (biggest win)

Replace the synchronous mass-print flow with a queue consumer. The order grid mass action or custom button dispatches one message per order (or one message with an order-id batch), a consumer generates the PDFs and stores the files, and the admin sees a link or a "ready" flag once the job finishes.

<!-- communication.xml -->
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:Communication/etc/communication.xsd">
    <topic name="sales.pdf.generate.request" request="string">
        <handler name="pdf.generation.handler" type="Vendor\Module\Model\Pdf\Consumer" method="process"/>
    </topic>
</config>

The consumer runs in a dedicated, monitored process with a higher memory limit than the admin pool (php -d memory_limit=1G bin/magento queue:consumers:start sales.pdf.generation), writes the finished files to a storage directory, and emits a notification with a download link. The admin request now takes milliseconds and returns instantly. This single change eliminates the 504s and the admin-pool memory crashes entirely.

2. Cache generated documents

If you keep synchronous generation (for example, the single-order print button), cache the rendered PDF keyed by document type + order/increment id + a content fingerprint, and invalidate when anything that appears on the PDF changes — a new comment, a shipment, a credit memo. The fingerprint can be as simple as a hash of updated_at plus the relevant statuses; store files under var/ or the media directory, never in the database. A plug-in on getPdf() is the clean interception point:

<!-- di.xml -->
<type name="Magento\Sales\Model\Order\Pdf\Invoice">
    <plugin name="vendor_pdf_cache" type="Vendor\Module\Plugin\PdfCache" sortOrder="10"/>
</type>

The same route helps the frontend customer-print case: the file is generated once and served as a static download afterwards, which also protects you from print-happy customers hammering the storefront.

3. Generate PDFs ahead of time

For high-volume stores, flip the order of work: generate the invoice PDF right after the invoice is created (or when it's finalized), triggered by an observer or a queue message, and store it. By the time a customer or admin asks for it, the file already exists. This turns a 2-second synchronous request into zero-cost delivery and completely decouples PDF CPU from storefront traffic.

4. Make the renderer cheaper

If you can't move generation off the request path, reduce the per-document cost:

Trim the layout. A module that overrides the PDF template classes can drop expensive columns (e.g., the extended options block, custom attributes, barcode images) or draw more items per page, cutting page count and glyph work.
Simplify images and fonts. The logo and any embedded images are re-encoded into every PDF; keep them small. Stick to the built-in core fonts (Helvetica, Times) — embedding custom TTF fonts forces font subsetting on every render.
Raise limits for the right pool only. Give the admin PHP-FPM pool (or the dedicated consumer pool) a higher memory_limit and pm.max_requests headroom, instead of raising limits globally for the storefront.

5. Replace Zend_Pdf entirely

When PDFs are a core part of your business (thousands of invoices a day), consider replacing the renderer. Options range from faster pure-PHP engines (TCPDF, FPDF) to HTML-to-PDF converters (Chromium headless, wkhtmltopdf, or a PDF API service). The catch: Magento's PDF classes are tightly coupled to Zend_Pdf's page object model, so a full swap means reimplementing Magento\Sales\Model\Order\Pdf\* classes with your own drawing layer while keeping the same public interface (getPdf()), and validating every document type against your templates. It's real module work — start with the batch-queue and cache steps above first, and only invest in a renderer swap if profiling shows PDF rendering is a permanent, dominant cost for your infrastructure.

Putting It Together

The default Magento 2 PDF pipeline is a pure-PHP drawing engine, running synchronously in a web request, rebuilding the same document every time, with cost proportional to line items — and the mass-print grid action multiplies that by the number of selected orders in one shot. The fixes are progressive and independent:

Queue the batch print flow — eliminate the 502/504 class of incidents overnight and move PDF CPU to monitored consumers with headroom.
Cache generated documents — make repeat prints and frontend customer prints instant static downloads.
Generate ahead of time if you invoice at scale — PDFs are cheap when nobody is waiting on them.
Trim layout and fonts to lower per-document cost, and scope memory limits to the generating pool only.
Replace the renderer only when profiling proves PDF generation is a dominant, permanent cost.

Start by timing getPdf() on your largest orders — the numbers will tell you which of the five steps pays off first. In most stores, step 1 alone turns a dreaded admin click into an instant response, and that's usually worth more than any renderer swap.

Magento 2 Bundle Product Performance: Why 'Build Your Own' Products Slow Down Your Store

Magevanta — Mon, 31 Aug 2026 09:04:34 +0000

Bundle products are the "build your own" workhorse of Magento 2 — a laptop with your choice of SSD, RAM and warranty; a gift box with three picked items; a PC configured per component. Merchants love them because they shift choice to the customer and lift average order value. What they don't love is the quiet way bundles multiply database rows, index work and request time exactly where they're already feeling it: price, stock, search and checkout.

A configurable product is a parent with fixed, discrete variations — one row per variation in the price index. A bundle is different: its price is computed from whatever combination of selections the customer picks. That single sentence is the root of nearly every bundle performance problem in Magento 2. This article walks through where the costs land, how to diagnose them, and a practical playbook to keep bundles fast.

Why Bundles Are Structurally Expensive

Every bundle product (module Magento_Bundle) is backed by child products: the individual selectable SKUs, hidden with visibility Not Visible Individually. The parent's price, stock status, weight and quote item only exist as a function of the selections. Concretely, that means:

Price is a range, not a value. The catalog price index must store the minimum and maximum possible price, per website, per store, per customer group — and every option selection a customer can make contributes to that math.
Stock is derived. The bundle's stock status is computed from the stock of all selection children (cataloginventory_stock_status gets rows for every child).
Quote items are compound. Adding one bundle to the cart creates the parent quote item plus one child quote item per selected option — typically 3 to 10 extra rows.

None of this is broken; it's just that bundles turn "one product" into "one product plus N children plus M computed values" across every subsystem. On a catalog with thousands of bundles, that multiplication reaches the databases, queues and caches at once.

1. The Price Index Multiplication

This is the biggest cost center. In catalog_product_index_price, a simple product is one row per website/group. A bundle explodes that with a dimension for every option selection:

-- Catalog tables that drive bundle price computation
SELECT table_name, table_rows
FROM information_schema.tables
WHERE table_name LIKE 'catalog_product_bundle%';

The relevant tables — catalog_product_bundle_option, catalog_product_bundle_selection, catalog_product_bundle_option_value — are small; the damage shows up in catalog_product_index_price, where each bundle's min/max price is computed by iterating option selections during reindex. With Magento_CatalogRule active, the bundle price rows multiply further, because rule prices are calculated against the same selection dimensions. The pattern is identical to the configurable product price explosion, except configurables have a fixed variation set while bundles can have combinations — the indexer can't precompute them, only bound them.

Diagnose it:

bin/magento indexer:status | grep -i price

If catalog_product_price is perpetually behind in Schedule mode or takes minutes in Update on Save mode and your catalog has bundles — the bundle selection count is your lever. Reduce options per bundle, reduce selections per option, and definitely avoid nested bundles (a bundle inside a bundle), which make the price computation recursive and multiply reindex time.

2. Stock, Reservations and the MSI Tax

Bundle availability is derived from children, and under Multi-Source Inventory every child is its own inventory item. The chain works like this:

Each selection child gets rows in inventory_source_item and inventory_stock — stock status is a computed aggregate per child.
A bundle's stock status is then aggregated from all its children — a per-request query chain that grows with bundle size.
On order placement, MSI writes one inventory reservation row per selected child. A 20-item bundle order generates 20+ reservation rows, accelerating the unbounded growth of inventory_reservation that most stores are already fighting.

The stock-status aggregation is especially visible when display_out_of_stock is enabled: every out-of-stock child forces the bundle's status computation to re-evaluate on category and product pages. Keep bundle children's stock management synchronous, avoid "infinite" option combinations (MSI computes availability per combination), and monitor inventory_reservation growth with the same cleanup cron you'd use for simple products — bundles just make it arrive sooner.

3. Quote, Cart and Checkout Bloat

Add a bundle to the cart and open quote_item:

1 parent row with product_type = 'bundle', plus
1 child row per selected option (parent_item_id set).

A checkout with five bundles therefore writes anywhere from 20 to 60 quote item rows — and those rows live until the quote is cleaned up. Every cart render (getItems()), every totals collector run, every minicart AJAX call touches all of them. In orders, the same multiplication continues into sales_order_item and follows through to the sales grid indexer.

Practical limits that keep this sane:

Cap options per bundle at 5–8, selections per option at 10–15.
Avoid re-rendering the cart: enable full-page cache and AJAX-driven cart (the defaults) so the minicart doesn't rebuild quote totals on every page view.
If you offer "pre-selected" bundles, remember they still create the full parent + child row set on add-to-cart — pre-selection saves rendering time, not quote volume.

4. Search and Category Pages

Bundle children are hidden with Not Visible Individually, which is good — they're excluded from the search index. But the parent bundle still carries a computed price range into layered navigation, and that creates a subtle issue: the price filter and price sorting must use the min price for ordering. If your SEO-friendliest bundles are also your most expensive at max configuration, they rank low in "price low-to-high" despite being competitive — a merchandising quirk, but also a hint that your search index is computing price ranges per query.

Where bundles genuinely hurt search is query time on large catalogs: price aggregation per bundle forces OpenSearch to evaluate the range per hit. Mitigate by keeping bundle children out of the index (default visibility does this) and by never enabling flat catalog alongside bundles — flat tables materialize every child attribute and historically break or balloon with composite products.

5. Rendering the Product Page

The bundle product page renders option widgets that must know each selection's price, stock and image. Out of the box that's a series of collection loads per option (getSelectionsCollection() per option id), which shows up as N+1 patterns when you profile the page. Look for:

-- Frequent offenders in the slow query log / profiler
SELECT ... FROM catalog_product_bundle_selection s
LEFT JOIN catalog_product_entity ... WHERE s.parent_product_id = ?

Each option = one such query chain. Fixes:

Warm the FPC. The bundle product page is fully cacheable for the anonymous customer. If your hit ratio is low, pre-warm bundle pages after reindexes — they're the most expensive product pages to build cold.
Batch the selections. Load all options for a product in one query (or via the bundle type's collection API with addFilterByRequiredOptions) and assemble options in memory instead of per-option loading.
Disable dynamic pricing display where you can: showing "from €X" per option on the product page triggers price recomputation per selection widget. If you only need the final price on selection, defer price rendering to the client-side price box.

The Bundle Performance Playbook

If you have bundles and they're slow, this is the order of operations:

Measure first. indexer:status for price/stock lag, information_schema row counts on catalog_product_bundle_*, and a profiler trace of the worst product page. Bundles rarely fail on one axis; know which one hurts.
Shrink the combos. Fewer options, fewer selections, no nested bundles. This single change reduces price index rows, stock aggregations, quote rows and product-page rendering at once — it's the highest-leverage fix.
Put price index on schedule with mview. Ensure catalog_product_price runs via mview changelogs so save-time reindex doesn't stall admin operations, and batch it off-peak.
Watch inventory reservations. Add the reservation cleanup cron before bundles become a big share of orders, not after the table hits tens of millions of rows.
Keep FPC warm. Bundle pages are cacheable; actively warm them and check X-Magento-Cache-Debug on the product page.
Consider the trade-off. If a "bundle" is really a fixed kit (three items, always the same), a grouped product or a simple product with a custom option set is structurally cheaper — same UX for the customer, none of the composite product machinery. Reserve true bundles for genuinely variable configurations.

Summary

Bundle products are one of the few Magento 2 features where the architecture — derived price, derived stock, compound quote items — multiplies cost across every performance-sensitive subsystem. They're not unmanageable, but they demand discipline: constrained option trees, scheduled indexers, warm caches and reservation hygiene. Audit your bundles with the checks above before Black Friday traffic finds them for you.

Magento 2 Catalog Permissions: The Hidden Full-Page Cache Killer

Magevanta — Sun, 30 Aug 2026 09:03:19 +0000

Your store was fast. Category pages served from full-page cache in single-digit milliseconds. Then someone enabled a "small B2B feature" in the admin, and suddenly every category page takes 800ms and the database CPU is pinned. If that feature was Catalog Permissions, you've just met one of the most under-documented performance traps in Magento 2.

Catalog permissions is a legitimate, powerful feature — it lets you control who can view categories, see prices, search, and check out, per customer group. But it comes with three hidden costs that most merchants discover only after the damage is done: full-page cache gets disabled on product and category pages, a permission index starts multiplying rows in the background, and every product collection query becomes heavier. This article walks through all three, how to diagnose them, and what to do when you genuinely need the feature.

What Catalog Permissions Actually Does

The feature (module Magento_CatalogPermissions) is enabled in admin under Stores → Configuration → Catalog → Catalog Permissions. Once turned on you get four grants per customer group and per website, overridable per category:

Grant Catalog Category View — who can browse a category tree
Grant Catalog Product Price — who can see prices
Grant Checkout Items — who can add to cart
Grant Catalog Search — who gets results in search

The defaults are configured per website and customer group in the admin, and individual categories can override them. On the surface it's clean and flexible. Under the hood it's the closest thing Magento 2 has to a global performance switch you can flip by accident.

Cost #1: Full-Page Cache Stops Working for the Pages That Matter

This is the big one. Once catalog permissions are enabled, product and category content becomes customer-group-dependent: two visitors from different groups can legitimately see different category trees, different products, different prices. The shared, cacheable version of a category page no longer exists.

Technically, Magento handles this via the permission-driven page context — the customer group becomes part of what determines page content, and for the affected pages the response is served as non-cacheable (you'll see Cache-Control: private / no-store in the headers instead of the Varnish-friendly public cache headers). In other words: every category and product page now hits PHP, Magento, and the database on every single request. A store that was doing 2,000 uncached pages per second on a warm Varnish setup suddenly needs the full stack to serve every category view.

The customer data sections mechanism handles small personalized blocks (mini cart, account links) on otherwise cached pages. It is not designed to rescue entire category listings or product pages — those are the page itself, not a block on it. No ESI trick or hole-punching workaround reliably restores caching for permission-gated listing pages; the content genuinely depends on who's asking.

Cost #2: The Permission Index Multiplies Like the Price Index

To avoid joining permission rules into every query at runtime, Magento builds a materialized permission index — think of it as a cousin of the price index: rows are pre-computed per website × customer group × category × product combination.

Do the math. Five customer groups, three websites, 2,000 categories, 100,000 products — even with sparsity (permissions cascade from category defaults, so not every combination gets a row), the index can grow to millions of rows. Every rebuild is a full scan of that space. Reindexing the permission indexers after a mass product or category update is one of those "why is my maintenance window suddenly 40 minutes" moments.

And this index isn't rebuilt once a day in quiet hours — it's an mview-based indexer, updated in near real time as category/products change. That means the growth also produces continuous changelog and indexer load on top of your regular indexers.

Cost #3: Every Collection Query Gets Heavier

With permissions enabled, product and category collections carry an extra permission resolution step. When Magento loads a product collection it must filter it by what the current customer group is allowed to see, and when it renders the category tree it checks every node against the permission matrix.

The typical symptoms:

Category pages with a normal number of products suddenly generate noticeably more queries and joins, visible in the slow query log and in query counts per request
The category navigation (the tree in the header/sidebar) gets slower, because every node needs a permission check — on a large category tree this alone can add tens of milliseconds
Search results are filtered per group too (that's the Grant Catalog Search grant), so search queries carry the same join overhead
Admin operations that load collections can slow down as well, since the permission logic applies to a lot of shared collection code paths

None of these are catastrophic individually — but stacked on top of a disabled FPC, each uncached request now pays all of them at once. That's the perfect storm: the cache that used to hide the query cost is gone, and the queries themselves got more expensive.

Diagnosing Whether Catalog Permissions Are Your Problem

If your storefront slowed down and you suspect this feature, the checks are quick:

1. Is the feature enabled?

SELECT scope, scope_id, path, value FROM core_config_data
WHERE path LIKE 'catalog/magento_catalogpermissions/%';

An enabled value of 1 means the feature is on. Also check the grants (grant_catalog_category_view, grant_catalog_product_price, grant_checkout_items, grant_catalog_search) — even if enabled, the effective restriction depends on their values.

2. Is FPC actually bypassed?
Fetch a category page with curl -I. A healthy cached response carries X-Magento-Cache-Debug: HIT and public cache headers. A permission-affected page shows private/no-store cache headers — that's the smoking gun.

3. What do the permission indexers look like?

bin/magento indexer:status | grep -i permission

The "Catalog Permissions" indexers (category + product) should be Schedule-managed and up to date. Check catalogpermissions_product_index row count and growth trend in the database — if it's in the tens of millions, the index itself is now a load factor.

4. Correlate the timeline.
Ask when the storefront slowed down and cross-reference with core_config_data timestamps or audit logs. In almost every real case, the slowdown date matches the day someone flipped the feature on.

First Question: Do You Actually Need It?

Before optimizing, question the requirement. A large share of "we need catalog permissions" requests can be solved cheaper:

"Wholesale customers shouldn't see retail products" → split catalogs across store views or websites instead. Different websites keep full-page cache fully working and give you separate categories, pricing, and even separate layered navigation setups.
"Wholesale customers pay different prices" → use customer group pricing / tier prices (or catalog price rules). Group-based prices are rendered through customer data sections, so pages stay cacheable while prices adapt per group.
"We want to hide some categories from the menu" → disable "Include in Menu" per category, or restructure the navigation. Zero permission machinery involved.
"Only logged-in B2B customers may see our full range" → this is where permissions genuinely shine — but read the next section before committing.

If the requirement is truly view-level gating by group with per-category overrides, catalog permissions is the right tool and you should keep it — just understand the trade-off and budget for it.

If You Must Keep It: The Optimization Playbook

You can't get FPC back for permission-gated pages — accept that. But you can keep the damage contained:

Keep the permission matrix coarse. The index cost grows with the number of customer groups, websites, categories, and products in play. Collapse groups where possible ("Retail", "Wholesale", "Guest" instead of ten micro-segments), and prefer group-level defaults with only a few category overrides instead of per-category rules everywhere.

Watch customer segments and permissions together. Combining both multiplies per-request work: segment conditions evaluate on top of the permission joins. If both are enabled, profile where the time actually goes — often the segments are the larger part.

Manage the permission indexers deliberately. Keep them on Schedule (mview) with sane batch sizes, and align their update windows with your other indexer load instead of letting them fight the main indexers for CPU during business hours. Monitor catalogpermissions_product_index growth — if it trends toward tens of millions of rows, your category/group structure is the problem, not the indexer.

Tune the database for the new query pattern. The permission joins hit the EAV and index tables heavily. Apply the usual medicine: proper composite indexes on the permission tables' foreign keys (website_id, customer_group_id, category_id, product_id), a healthy buffer pool, and query analysis after enabling the feature — the slow query log will tell you exactly which joins need help.

Revisit the search grant. If wholesale needs a separate search experience, check whether both groups really need full-catalog search. Restricting search to a subset changes the search index relevance work, and it's one more place where the permission join runs on every query.

Load test before rolling out. Enable permissions in staging, run your load tests against the uncached permission-gated pages, and measure exactly what "no more FPC" costs you in your traffic mix. Decide whether the business value of the feature justifies the extra PHP-FPM and database capacity — and whether your PHP-FPM tuning can absorb it.

The Bottom Line

Catalog permissions is a dangerous default-on-by-accident feature: it silently disables full-page cache on product and category pages, multiplies an index table, and adds permission joins to nearly every collection — all for the cost of a checkbox. Before enabling it, confirm the business requirement genuinely needs per-group view gating, not just different pricing or menu structure. If it does, keep the permission matrix coarse, manage the indexers deliberately, and load-test the uncached reality.

And if your store already slowed down and you never consciously enabled this feature — check core_config_data for catalog/magento_catalogpermissions, check the cache headers on a category page, and check the permission index size. In the majority of cases, the "mysterious B2B slowdown" is just this one toggle doing exactly what it says on the tin.

Magento 2 MariaDB vs MySQL: Choosing the Database Server That Won't Slow You Down

Magevanta — Sat, 29 Aug 2026 09:03:58 +0000

Ask most Magento 2 teams which database server they run and you get a shrug. It came with the hosting plan, the VPS image, or the Docker container. But "MySQL-compatible" is not "the same server" — and on a platform that fires hundreds of small queries per page view, the differences between MySQL and MariaDB can show up in your slow query log sooner than you think.

This article compares both servers from a Magento 2 perspective: version support, optimizer behaviour, clustering, the gotchas that bite during migration, and a practical decision framework for your next server build.

Why the Choice Matters More Than You'd Expect

Magento 2 is a query machine. A category page with 24 products can easily trigger 300+ queries once cache misses kick in — EAV attribute lookups, price index reads, URL rewrites, stock reservations. The database server sits in the critical path of every uncached request, every indexer run, and every checkout.

The good news: for this exact workload, MySQL 8.0 and MariaDB 10.6+ are within a few percent of each other when both are tuned properly. The bad news: they differ in defaults, optimizer behaviour, and operational tooling — and those differences decide how much tuning you need, which extensions break, and how painful your next migration is.

Version Support: What Adobe Actually Allows

Adobe officially supports both. As of Magento 2.4.7 and 2.4.8, the system requirements list MySQL 8.0.x and MariaDB 10.6+ (earlier 2.4 releases also accepted MariaDB 10.4/10.5). Percona Server 8.0 is the third supported option and sits close to MySQL with extra tooling.

What this means in practice:

MariaDB 10.6 is the safe floor. Anything below 10.4 is unsupported territory — and plenty of cheap hosts still ship 10.3 or even 10.1. Check before you buy.
MariaDB 11.x is running on a rebased InnoDB. Starting with 11.0, MariaDB's InnoDB is forked from the MySQL 5.7 code base rather than 8.0. Functionally it works fine for Magento, but some features and optimizations from MySQL 8's InnoDB are absent, and the community has reported mixed performance results. Test before you adopt.
MySQL 8.0 is the default if your stack is built around it. If your host offers both, either is defensible — see below.

The Compatibility Gotchas That Bite During Setup

Most "it worked on my old host" breakages when switching between the two come from these four areas:

1. Authentication plugins

MySQL 8.0 changed the default authentication plugin to caching_sha2_password. Modern PHP (7.4+, so any Magento 2.4.8 stack) handles this fine, but if you're connecting with an older connector, a legacy tool, or a monitoring agent, you'll get an immediate Access denied for user — even with the correct password. The quick fix is creating the Magento user with mysql_native_password, but plan for it instead of debugging it at 2 AM during a migration.

2. SQL mode defaults

MySQL 8 defaults to ONLY_FULL_GROUP_BY and STRICT_TRANS_TABLES; MariaDB's default set differs slightly. Third-party extension SQL that was written for MariaDB's looser grouping semantics can throw errors on MySQL — and vice versa. If you migrate and suddenly see SQL errors from extensions you didn't touch, check sql_mode first.

3. Feature parity gaps

Both support window functions, CTEs and common index types, but not identically. MariaDB has no direct equivalent of MySQL 8's INVISIBLE indexes or hash-join cost model tuned the same way; MySQL lacks MariaDB's system-versioned tables and SEQUENCE engines. Magento core rarely touches these, but custom modules and reporting queries sometimes do — grep your codebase's raw SQL before switching.

4. JSON handling

Magento 2 itself barely uses JSON columns, but extensions (especially headless/custom-api modules) do. MySQL 8 has native JSON with generated-column indexing; MariaDB treats JSON as an alias for LONGTEXT with a validation check. Queries that rely on ->> or generated indexes behave differently. If your stack uses JSON columns heavily, this can be a deciding factor.

Performance: Where They Actually Differ

For a Magento workload, benchmark suites usually land close — within 5–10%, and the winner flips depending on the query mix and config. The structural differences that matter:

Aspect	MySQL 8.0	MariaDB 10.6+
InnoDB base	8.0 line, continuously improved	5.7 fork (10.6), 5.7-based (11.x)
Optimizer	Cost model, hash joins, descending indexes, invisible indexes	Good cost model, some 5.7-era optimizations; no hash joins until recently planned
Thread pool	Enterprise only	In community server
Clustering	Group Replication / InnoDB Cluster (MySQL Shell)	Galera (mature, battle-tested)
Performance Schema	On by default, measurable overhead	Available, lighter default footprint
Backup tooling	mysqlbackup / xtrabackup (8.0-compatible builds)	mariabackup (drop-in for xtrabackup)
Extras	Resource groups, `EXPLAIN ANALYZE`	System-versioned tables, `ANALYZE FORMAT=JSON` counter-part, more storage engines

Two things matter more than the brand:

Configuration is 90% of the game. Either server will crawl with default config on a Magento store. innodb_buffer_pool_size sized to your dataset, sensible innodb_flush_log_at_trx_commit, join_buffer_size for the infamous EAV joins — these matter far more than which server binary you run. If you haven't tuned these yet, start with our database index strategy guide before switching servers.

The optimizer makes different choices. The same query can take a different plan on each server because the cost models differ. That means: after migrating, re-check your slow query log and your indexer performance. A query that used index A on MySQL may use a full scan on MariaDB — or vice versa. This is normal, and it's the #1 reason a migration "feels slower" even though the hardware didn't change.

Clustering and Replication

If you're running more than one database node, the decision gets more interesting:

MariaDB Galera is the classic synchronous multi-master setup. Mature, widely deployed, and it works well with Magento's read/write splitting patterns — just be careful with the write-hotspots (cart, sales_order, inventory_reservation) that can cause certification conflicts and deadlocks.
MySQL InnoDB Cluster / Group Replication is the modern equivalent. Tighter integration with MySQL Shell and Router, but with a steeper learning curve and its own quirks (e.g., multi-primary limitations, stricter membership handling).

For most Magento stores — even fairly large ones — a single well-tuned node with async replica(s) is the right architecture regardless of brand. Clustering is a scale pattern, not a default.

Migration Checklist: Switching Without a Fire Drill

If you're moving from one to the other, treat it as a project, not a mysqldump | mysql one-liner:

Read the version matrix. Confirm your Magento version supports the target server version — check the official requirements.
Stage it first. Stand up the target server, restore a full backup, and run your real indexers + a smoke test on the storefront.
Compare query plans. Capture the top 20 slow queries before migration, run them on the target, and diff the EXPLAIN output. Expect differences; fix what regressed.
Check extensions. Any module doing raw SQL, JSON columns, or GROUP BY without care is suspect. Test the ones you can't live without.
Re-tune config. Don't copy my.cnf verbatim — innodb_buffer_pool_size and related InnoDB variables map across, but optimizer and thread settings differ. Start from the target server's defaults + your buffer-pool sizing.
Use the right backup tool. mariabackup for MariaDB, xtrabackup 8.0 for MySQL. Logical dumps (mysqldump) work but are slower and heavier for multi-GB catalogs.
Watch the first week. Slow query log, deadlock log, and indexer runtime. Schedule a database maintenance pass shortly after.

How to Decide: A Practical Framework

Choose MySQL 8.0 if:

Your team already operates MySQL / Percona in production
You rely on JSON columns, generated columns, or EXPLAIN ANALYZE
You want MySQL 8's optimizer features (hash joins, descending indexes)
Your host's managed service is MySQL-based (RDS, Cloud SQL)

Choose MariaDB 10.6+ if:

Your host ships MariaDB (cPanel, most cheap VPS images) and you want the supported default path
You want Galera for synchronous multi-master
You value the thread pool in community builds for high concurrent-connection workloads
Your team knows MariaDB tooling (mariabackup, mysql CLI compat)

Avoid the brand debate entirely if: you're running a single node and your slow queries, buffer pool, and indexes are untuned. That's where your performance actually lives. Switching servers to fix a slow store is like changing the oil brand to fix a flat tire.

The Bottom Line

MySQL 8.0 and MariaDB 10.6+ are both fully capable Magento 2 database servers. For the typical store the performance difference is noise compared to configuration, indexing and query design. Choose based on what your host provides and what your team can operate — then invest your time in the things that actually move the needle: buffer pool sizing, composite indexes on the EAV and price tables, archiving old sales and quote data, and a decent connection pool so MySQL/MariaDB never becomes the wall between PHP-FPM and your data.

Magento 2 Load Testing & Capacity Planning: Know Your Limits Before Traffic Does

Magevanta — Fri, 28 Aug 2026 09:03:06 +0000

Every Magento 2 team has the same nightmare: a flash sale goes live, traffic triples, and the site turns into a spinning wheel of death. The store survives — barely — but orders drop, support tickets explode, and the post-mortem reveals the same sentence: "We didn't know it would break at that load."

You can know. Load testing is the difference between guessing your limits and measuring them. This article covers the full loop: designing realistic tests, generating load that actually resembles your shoppers, reading the results to find the real bottleneck, and turning those numbers into capacity decisions.

Why Load Testing Is Not Regression Testing

If you've read our article on automated performance regression testing in CI, you know that's about catching slowdowns between deploys — a few requests, tight budgets, fail the build if TTFB climbs.

Load testing answers a different question: how much traffic can this system handle before it degrades or dies? One focuses on change detection; the other on absolute capacity. You need both. Regression testing keeps you from getting slower; load testing tells you where the cliff is, and whether one node survives a flash sale or you need five.

Define What "Good" Means Before You Start

A load test without acceptance criteria is just a benchmark with anxiety. Define SLOs first, ideally from real traffic data:

p95 Time To First Byte (TTFB) under load — e.g., under 800ms
Error rate — under 0.5% (502s, timeouts, checkout failures)
Throughput — X requests/second sustainable for 30+ minutes
Business metrics — successful checkout completion rate over 99%

Then define the shape of traffic. Magento 2 is not a static site: different pages cost wildly different amounts. A realistic mix for a typical store looks something like:

40% category/product listing pages (PHP + FPC + Elasticsearch aggregations)
30% product detail pages (heavily cached, cheap when warm)
15% home + CMS pages (nearly free with FPC)
10% cart + checkout actions (uncached, DB-heavy, the real load)
5% search, account, and API calls

Also model the audience. Returning customers with a valid session hit a different code path than anonymous shoppers — customer data sections, personalized blocks, and lesser FPC coverage. If 60% of your real traffic is logged in, a test with 100% anonymous visitors will flatter you dangerously.

Build a Test Environment That Looks Like Production

The #1 load-testing mistake: testing on a sandbox with 50 products, one customer, and a cold cache — then believing the results apply to your 200k-SKU storefront.

Your test environment needs:

Production-sized data. Same catalog size, same attribute count, realistic customer and quote tables. EAV lookups and index tables behave completely differently at 10k vs 200k SKUs.
Production-equivalent config. Same number of PHP-FPM workers (or scaled proportionally), same Redis setup, same Elasticsearch/OpenSearch cluster layout, same Varnish/FPC strategy.
Warm cache tests first, cold cache tests second. A warm-cache test measures steady-state capacity — what shoppers experience 99% of the time. A cold-cache test (flush Varnish + Redis, burst traffic) simulates the worst minutes after a deploy or a cache invalidation storm. Both are informative; most teams only test one.
Run load from a different machine. The load generator should never share resources with the app server. If possible, generate traffic from outside your CDN too — you want to see the origin's real behavior, not just the CDN's edge.

Tooling: k6 or JMeter?

For Magento 2 specifically, both work; pick based on your team:

k6 — scriptable in JavaScript, excellent ramp-up/ramp-down stages, cheap to run in CI, and produces clean threshold-based pass/fail. Great if you want to reuse the same journey definitions between load tests and synthetic checks.
JMeter — heavyweight, GUI-driven, familiar to many QA teams, with a huge plugin ecosystem (including Magento-specific CSV data sets or correlation helpers).
Locust — Python, fine for simple journeys, but its event loop can become the bottleneck at high concurrency.

A minimal k6 journey for a shopper flow looks like this:

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 50 },   // ramp up
    { duration: '20m', target: 50 },  // steady state
    { duration: '2m', target: 0 },    // ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<800'],
    http_req_failed: ['rate<0.005'],
  },
};

export default function () {
  // Anonymous browse: home → PLP → PDP
  const home = http.get('https://store.example.com/');
  check(home, { 'home 200': (r) => r.status === 200 });

  const plp = http.get('https://store.example.com/women/tops.html');
  check(plp, { 'plp 200': (r) => r.status === 200 });

  const pdp = http.get('https://store.example.com/example-product.html');
  check(pdp, { 'pdp 200': (r) => r.status === 200 });

  // Every Nth iteration: add to cart + go to checkout (uncached, heavy)
  if (__ITER % 10 === 0) {
    // In reality: carry form_key from the PDP, POST to checkout/cart/add
    const cart = http.post('https://store.example.com/checkout/cart/add/uenc/...');
    check(cart, { 'cart add 200': (r) => r.status === 200 });
  }
  sleep(3); // realistic think time between pages
}

The think time matters more than people assume. 50 virtual users hammering pages back-to-back with zero delay is 50 users acting like robots — your real visitors read, scroll, compare, and hesitate. Without think time you'll overestimate load on cheap cached pages and misread the results.

Extract the Right Data From the Test

A load test produces two data sets: the client-side response times, and the server-side telemetry. The second one is where the diagnosis lives. During the test, watch:

PHP-FPM. Is pm.max_children exhausted? You'll see listen queue grow and 502s appear. This is the classic first bottleneck for PHP apps.
MySQL/MariaDB. Run SHOW PROCESSLIST and watch Threads_running, Threads_connected, and slow query log entries. A wave of identical slow queries (often the same category listing or price filter query) points straight at the culprit.
Redis. INFO stats — look at evicted_keys and rejected_connections; evictions under load mean the cache is thrashing, not helping.
Elasticsearch/OpenSearch. Watch search latency and rejection counts (thread_pool stats). Faceted navigation is often the hidden load generator.
nginx access log. Triage the response code mix and the slowest URLs. awk over the log for p95 per URL pattern tells you which page types degrade first.

The bottleneck is almost always a queue filling up: PHP-FPM workers, DB connections, or search threads. When response times climb linearly while CPU idles, you're queueing somewhere — find the queue.

Reading the Results: The Three Load Phases

Healthy systems show three phases in a ramp-up test:

Linear phase — response time stays flat as concurrency grows. The system is bored. This is your linear capacity region.
Knee phase — response time starts climbing, but throughput still grows. Some queue is starting to fill.
Cliff phase — throughput plateaus or drops, error rate spikes. Saturated. This is your breaking point.

Never capacity-plan at the cliff. Plan at the knee: the concurrency where p95 stays inside your SLO. If your knee is at 40 concurrent sessions per node and you expect 400 at peak, you need ~10 nodes with zero headroom — plan for 30-40% headroom on top of that for spikes, deploys, and cache misses.

Turning Numbers Into Capacity Decisions

This is where load testing pays for itself. Concrete examples of decisions the test output should drive:

Node count. One web node sustains X req/s at p95 under SLO → peak demand is 3.5X → you need 4-5 nodes, not 2.
Autoscaling thresholds. Set scale-out at 60-70% of the knee value, not at error-rate spikes. Scaling on errors is like braking after the crash.
Where to spend money. If the bottleneck is MySQL connection saturation, buying two more web nodes won't help — add a read replica or enable connection pooling instead. Load tests redirect your budget from symptoms to cause.
Cache warming before launches. If the cold-cache test fails and the warm-cache test passes, your launch procedure needs a warming step (sitemap crawl or prioritized warm) before traffic switches over.
Queue-based offloading. If checkout actions are the cliff, move email, order export, and inventory updates to async message queues so a traffic spike doesn't compound into a DB pileup.

When to Test — And How Often

Before every major event: Black Friday, seasonal sales, product launches, flash deals. Re-run the test with the expected peak traffic at least a week ahead — enough time to fix what it finds.
After architecture changes: moving to a new hosting stack, adding a CDN, switching search engines, changing PHP versions. Every one of these shifts the knee.
Quarterly baseline: as your catalog grows, your capacity profile drifts. A quarterly 30-minute soak test keeps your numbers honest.
After the fact — always validate. During your next real peak, compare actual server metrics to the test predictions. If reality is 2x better or worse than the test, your test data or think times are off — fix the model, or the next test will lie to you again.

The Bottom Line

Load testing doesn't prevent traffic spikes — but it removes the surprise. It tells you exactly how many requests your stack absorbs before it complains, where the bottleneck lives, and what one more euro of infrastructure should buy (another node, a replica, or a cache). Combined with CI regression testing, it forms the complete picture: you stay fast and you know your limits.

Run warm and cold tests, model real shopper behavior, watch the server-side queues during the run, and plan at the knee with headroom. Do that before the next flash sale, and the only thing spinning will be your load generator — not your storefront.

Magento 2 Vite Build Pipeline: The Modern Frontend Bundle Path

Magevanta — Thu, 27 Aug 2026 09:01:43 +0000

For years, compiling frontend assets in Magento 2 meant one of two things: the classic bin/magento setup:static-content:deploy pipeline backed by a Grunt/Stylus/css-m stack, or the endless patience required to watch that pipeline churn through thousands of theme files. If you've ever run a full multi-locale static content deploy on a large site, you know the pain: minutes of CSS and JS processing, a flood of pub/static files, and deployment pipelines that stall waiting for the frontend to finish.

Starting with Magento 2.4.7, Adobe added experimental support for Vite — the modern JavaScript build tool built on esbuild and Rollup. It's a faster, cleaner, more maintainable way to compile your theme assets, and it directly attacks one of the most frustrating performance problems in the Magento ecosystem: slow, opaque frontend builds.

This article is a practical guide to the Vite build path for Magento 2: what it replaces, how to turn it on, what the trade-offs are, and whether it's right for your store yet.

Why the Classic Pipeline Struggles

The traditional Magento frontend build has a few structural problems:

It's a multi-tool chain. Grunt orchestrates, Stylus preprocesses CSS, the css-m task modularizes, and setup:static-content:deploy copies, merges, and minifies. That's a lot of moving parts with a lot of I/O between them.
It processes everything, every time. Unless you carefully scope themes and locales, the deploy builds every theme and every locale's assets, copying thousands of files into pub/static.
It's slow to iterate. During development, full deploys are brutally slow, which pushes developers toward half-measures and skips.

Vite replaces essentially this entire chain with a single modern tool that compiles dramatically faster and offers a proper development server with hot module replacement (HMR).

How Experimental Vite Works in Magento

Magento's Vite integration is opt-in and experimental in 2.4.7/2.4.8. Under the hood it adds a vite.config.js that Magento generates, uses @vitejs/plugin-vue and Vite's core bundling to handle your theme's CSS and JS, and maps the translated/processed output back into pub/static so the rest of Magento (layout XML, templates, RequireJS loading) keeps working.

The key idea: instead of Magento's Grunt-driven task list, Vite does one clean compile pass with esbuild (for transforms) and Rollup (for bundling). For most themes the result is significantly faster builds and a much nicer developer experience.

Enabling the Vite Build Path

Because the feature is experimental, enabling it requires a few explicit steps rather than a bin/magento setup:upgrade magic switch:

# 1. Ensure you have Node and the Vite toolchain available in your environment
npm install -g vite @vitejs/plugin-vue

# 2. Generate the Vite config for your theme
bin/magento config:set dev/front_end_development_workflow/type vite
bin/magento config:set dev/static/sign 0

# 3. Re-run the app config import so the config takes effect
bin/magento app:config:import

# 4. Generate the vite.config.js files
bin/magento setup:config:vite

The dev/front_end_development_workflow/type config value is what flips Magento from the legacy Grunt workflow to the Vite workflow. You'll also want to disable the static-content signature for local/dev work (dev/static/sign 0) because Vite's dev server handles that part differently.

After generating the config, you can run the Vite build directly:

# Production build for your theme
vite build

And for development, start the Vite dev server, which gives you instant feedback via HMR instead of waiting on a full deploy:

vite

What Actually Gets Faster

The measurable wins come in a few places:

1. Build time

esbuild compiles TypeScript/JavaScript at a fraction of the time of the old toolchain, and the single-pass nature of Vite avoids the repeated file copying and processing of the legacy chain. On large theme codebases, developers commonly see build times drop from minutes to seconds — which matters for both your CI deploy pipeline and daily developer iteration.

2. Development feedback loop

The Vite dev server with HMR is the single biggest quality-of-life improvement. A developer editing a .scss file sees the change in the browser almost instantly, without a full static deploy. That removes a constant incentive to skip testing or rush deployments.

3. Bundle output

Rollup produces tree-shaken, minified production bundles. If your theme's JavaScript was pulling in more than it used, you'll often end up with smaller final bundles and better first-load performance.

Important Caveats Before You Adopt It

Being experimental, the Vite path is not a drop-in replacement for every store yet:

It's not the default. Adobe positions it as a preview for the future direction of Magento's frontend tooling, not as a fully supported production path in 2.4.7.
Compatibility is limited. Third-party modules and themes that rely on the legacy Grunt/less/css-m pipeline, or that inject assets through the old deploy hooks, may not behave correctly under Vite. Audit your custom and third-party frontend code before switching.
RequireJS interplay. Magento's module-based JS loading is built around RequireJS. Vite's bundling model is different, so you need to verify your module JavaScript still loads in the right order and scopes.
CI changes. Your deploy pipeline must now run vite build (and have Node + Vite available) instead of (or alongside) setup:static-content:deploy. That's a real infrastructure change, not just a flag flip.

Should You Switch?

My honest take: wait unless you're building a new theme or running a 2.4.8+ store with a fully controlled frontend stack. For a new custom theme with no legacy dependencies, the Vite path is an excellent, faster, more pleasant workflow worth adopting early. For a mature enterprise store running dozens of third-party modules and a heavily customized theme, the compatibility risk outweighs the build-time savings for now — but it's absolutely worth running a branch experiment to measure the difference on your own theme.

Either way, this is the direction Magento's frontend tooling is heading. Familiarizing yourself with the Vite path now puts you well ahead of the curve when it becomes the default.

Key Takeaways

Vite replaces the Grunt/less/static:deploy chain with a modern esbuild + Rollup pipeline.
Enable it via dev/front_end_development_workflow/type = vite plus setup:config:vite to generate the config.
The dev server with HMR and drastically faster builds are the biggest wins.
Treat it as experimental: audit third-party modules, adjust CI, and verify RequireJS loading before going all-in.
For new, controlled themes it's a genuinely better workflow; for complex legacy stores, run a branch pilot first.

Frontend build performance doesn't get as much attention as Redis or Varnish, but it's the layer your developers and your deploy pipeline touch on every single release. Modernizing it with Vite is one of the few changes that improves both developer velocity and the code you ship.