DEV Community: Magevanta

Magento 2 Cart Price Rules Performance: Optimize Complex Promotions at Scale

Magevanta — Wed, 17 Jun 2026 09:02:23 +0000

Cart price rules are one of Magento's most powerful marketing features — and one of the fastest ways to tank your store's performance if you're not careful.

When you have hundreds of active rules, millions of coupon codes, or complex conditions spanning multiple product attributes, every cart update can trigger an expensive rule validation cycle that turns a smooth checkout into a sluggish mess.

In this guide, I'll walk you through why cart price rules slow things down, how to measure the impact, and what you can do about it — from rule design and indexing to caching and database optimization.

Why Cart Price Rules Are Expensive

Every time a customer adds, removes, or updates an item in their cart, Magento re-validates all active cart price rules. Here's what happens under the hood:

All active rules are loaded — Magento fetches every active rule from salesrule and related tables
Conditions are evaluated — Each rule's conditions are run against the current quote, which means loading product data, customer group data, and sometimes even address/category data
Coupon codes are checked — If a coupon is present, Magento validates it against the salesrule_coupon table
Free shipping & discounts are computed — Applied amounts are recalculated for every quote item
The result is cached per quote — But the cache is invalidated on every cart change

The performance impact grows exponentially with:

Number of active rules
Complexity of conditions per rule
Number of items in the cart
Number of coupon codes in circulation

Measuring Rule Validation Time

Before optimizing, measure your baseline. The quickest way is to check the salesrule validator execution time using a simple profiling plugin:

// app/code/Vendor/Module/Plugin/TimingPlugin.php
public function aroundProcess(
    \Magento\SalesRule\Model\Validator $subject,
    callable $proceed,
    $address
) {
    $start = microtime(true);
    $result = $proceed($address);
    $elapsed = (microtime(true) - $start) * 1000;
    if ($elapsed > 200) {
        // Log slow rules — identify which rule IDs trigger long runs
        Mage::log("SalesRule validation took {$elapsed}ms", Zend_Log::WARN);
    }
    return $result;
}

You can also check MySQL's slow query log for the salesrule_coupon and salesrule queries:

-- Enable slow query logging temporarily
SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 1; -- 1 second

After collecting data, look for:

Queries on salesrule_coupon taking >500ms
Multiple sequential rule condition evaluations per cart update
High query count for salesrule_customer_group, salesrule_website, salesrule_label

Rule Design Best Practices

1. Combine Rules Instead of Duplicating

The single biggest mistake is creating one rule per product, category, or customer segment. If you have 500 rules for 500 products, Magento evaluates every single one on every cart change.

Instead: Use wildcard conditions or combine rules using SQL-level conditions. For example:

❌ Bad: One rule per product SKU (500 rules)
✅ Good: One rule with condition "SKU starts with PROMO-" + category condition (1 rule)

If you genuinely need per-product rules, consider whether a catalog price rule or tier pricing would work instead — these are evaluated at index time, not checkout time.

2. Keep Conditions Simple

Each condition in Magento's rule engine adds a JOIN or subquery to the evaluation SQL. A rule with 10 conditions can generate a query with 10+ JOINs.

Priority of condition types (from cheapest to most expensive):

Customer group — Single indexed column lookup (cheapest)
Website — Same, indexed FK
Grand total / Subtotal — Simple numeric comparison
Number of items — COUNT query, relatively cheap
SKU — Can be expensive if using array conditions
Category — Requires EAV category path lookup
Attribute conditions — Can involve EAV joins, very expensive
Subselection conditions — Most expensive, nested queries

Rule of thumb: Put the cheapest conditions first and use as few as possible. A rule with just "customer group = wholesale" + "subtotal > €100" will be evaluated in milliseconds. A rule with 8 attribute conditions and a category subselection can take seconds.

3. Avoid "All Items" Conditions Where Possible

Conditions that say "If ALL of these conditions are TRUE" (vs "If ANY") trigger full cart iteration. For stores with 50+ item carts, this adds up fast.

If you need per-item conditions, make sure they're on indexed attributes (SKU, category path) and keep the total under 5 conditions per rule.

Coupon Code Performance

Coupon Generation at Scale

Generating a few thousand coupons is fine. Generating a few million — which happens with large email campaigns — requires careful planning.

The salesrule_coupon table stores every single generated code. When a customer enters a coupon code, Magento searches this table with:

SELECT * FROM salesrule_coupon 
WHERE code = :code AND (expiration_date IS NULL OR expiration_date >= :now)

Without proper indexing, this query scans the entire table. Always ensure you have these indexes:

-- Check existing indexes
SHOW INDEX FROM salesrule_coupon;

-- Essential: code + rule_id compound index
ALTER TABLE salesrule_coupon ADD INDEX IDX_SR_COUPON_CODE_RULE (code(32), rule_id);

-- If using expiration dates frequently
ALTER TABLE salesrule_coupon ADD INDEX IDX_SR_COUPON_EXPIRATION (expiration_date);

Coupon Code Prefix Strategy

Use coupon prefixes instead of generating millions of individual codes. Magento supports coupon code prefixes natively in the admin panel.

Example: Instead of generating 100,000 individual codes like SUMMER-00001 through SUMMER-100000, create one rule with coupon prefix SUMMER- and let Magento validate the pattern rather than looking up individual codes.

This cuts the salesrule_coupon table from millions of rows to just one.

Clean Up Expired Coupons

Set proper expiration dates on all coupon-based rules and clean up expired codes periodically:

-- Archive expired coupons (run weekly via cron)
DELETE FROM salesrule_coupon 
WHERE expiration_date < DATE_SUB(NOW(), INTERVAL 90 DAY) 
AND times_used = 0;

Keep coupons that have been used — you need those for order history integrity.

Indexing & Database Optimization

Rule Index Tables

Magento's salesrule_product_attribute table is a flat index mapping rules → products → attributes. When this table grows large, it can slow down attribute-based conditions.

-- Check its size
SELECT COUNT(*) as cnt, 
       ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb
FROM information_schema.tables 
WHERE table_name = 'salesrule_product_attribute';

If this table exceeds 100MB, consider:

Reducing number of attribute-based conditions
Removing old/expired rules from the index
MariaDB performance: Partitioning this table by rule_id or attribute_id

Newsletter Coupon Tables

If you use Magento's newsletter coupon functionality, the newsletter_problem and related tables can bloat. Clean them during off-peak hours:

OPTIMIZE TABLE salesrule;
OPTIMIZE TABLE salesrule_coupon;
OPTIMIZE TABLE salesrule_product_attribute;
OPTIMIZE TABLE salesrule_customer;
OPTIMIZE TABLE salesrule_customer_group;
OPTIMIZE TABLE salesrule_website;

Caching Strategies

Cart Price Rule Cache

Magento 2 has built-in caching for rule validation results through the validate cache type and the quote's trigger_recollect flag.

Key tip: Disable the recollect trigger for every single cart page load if you're not displaying discount changes live:

<!-- etc/frontend/di.xml -->
<type name="Magento\Quote\Model\Quote">
    <plugin name="disable_recollect_on_load" 
            type="Vendor\Module\Plugin\DisableQuoteRecollect" />
</type>

This prevents the full rule validation from running on every GET cart page load — it only runs when the cart actually changes.

Varnish & Full Page Cache

Cart price rules are dynamic content — they can't be cached in FPC. However, you can use ESI (Edge Side Includes) or Varnish hole-punching to isolate the cart price rule output:

# In varnish.vcl — only if your theme supports it
sub vcl_recv {
    if (req.url ~ "^/checkout/cart/") {
        # Don't cache the cart page — rules are dynamic
        return (pass);
    }
}

Alternatively, if you use a microservice approach for cart calculations (like Vue Storefront or PWA), move price rule computation to a dedicated service that can handle the load independently.

Real-World Performance Gains

Here's what a real Magento store achieved after applying these optimizations:

Optimization	Before	After
Rule conditions per rule	8-12	3-4
Active rules	340	42 (combined)
Coupon codes	2.1M	14K (prefix pattern)
Cart validation time (10 items)	2.3s	280ms
Checkout page load	4.1s	1.2s

The biggest win? Combining 300+ individual product rules into three category-based rules, and switching to coupon prefixes.

Summary Checklist

Here's your quick action plan:

Audit — Count active rules, measure validation time with a profiling plugin
Combine — Merge rules with similar conditions; prefer catalog price rules where possible
Simplify — Reduce condition complexity, use cheapest condition types first
Index — Verify salesrule_coupon indexes; add compound indexes if missing
Prefix — Use coupon code prefixes instead of bulk generation
Purge — Clean expired, unused coupons regularly
Cache — Minimize trigger_recollect on cart page views
Monitor — Keep an eye on salesrule_product_attribute table size

Cart price rules don't have to be a performance nightmare. By designing rules thoughtfully, indexing properly, and cleaning up regularly, you can run hundreds of promotions without slowing down a single checkout.

Magento 2 Large Catalog Performance: Scaling Beyond 100K Products

Magevanta — Mon, 15 Jun 2026 09:13:40 +0000

Running Magento 2 with tens of thousands of products is one thing. Crossing the 100K threshold — or pushing toward a million SKUs — is an entirely different ballgame. The architecture that hums along happily at 10K products starts showing cracks: category pages that take 5+ seconds, layered navigation that times out, indexers that run for hours, and an admin panel that's barely usable.

The good news? Magento 2 can absolutely handle catalogs of this size. It just needs the right configuration, the right extensions, and the right approach. Here's what actually matters.

The EAV Bottleneck: Your First Wall

Magento 2's EAV (Entity-Attribute-Value) data model is flexible but brutal at scale. Every product page load can generate dozens of JOIN queries against catalog_product_entity_* tables. At 10K products this is fine. At 200K, it becomes a database killer.

What to do:

First, evaluate which attributes genuinely need to be searchable, filterable, or visible in product listings. Every attribute flagged as "Filterable" or "Used in Product Listing" adds weight to the EAV queries. In a large catalog, only the attributes your customers actually use should be enabled.

Second, use the catalog_product_flat tables — but with caution. Flat tables denormalize EAV data into a single row per product, which can dramatically speed up category and listing queries. However, they come with trade-offs: longer reindex times, increased storage, and complexity with multi-store setups. For catalogs over 500K products, flat tables may actually hurt more than help — test aggressively.

Third, consider moving attribute-heavy lookups to Elasticsearch or OpenSearch. The search engine handles faceted navigation far more efficiently than MySQL EAV queries. This is the single biggest win for large catalogs.

Category Tree Navigation at Scale

Category pages are often the most visited pages on a Magento store. With a large catalog, rendering a category tree with thousands of products and deep nesting becomes expensive.

Key optimizations:

Limit category depth. Deeply nested categories (5+ levels) generate recursive queries that don't scale. Flatten your tree where possible.
Use full-page caching aggressively. Category pages are cacheable by default. Ensure your TTL is reasonable and that cache warming covers your top 100-200 categories.
Anchor categories are expensive. An anchor category inherits products from all subcategories. With large catalogs, an anchor category near the root can represent 80% of your catalog. Use anchor sparingly.
Consider pagination size. 24 products per page means more page loads and more queries. For B2B catalogs, 48-96 per page can reduce server load. Don't offer "Show All" — it will crash.

Layered Navigation: The Performance Killer

Layered navigation (filterable attributes on category pages) is often the #1 performance problem in large catalogs. The default Magento implementation queries the EAV index tables, which can be catastrophically slow with 200K+ products.

Solutions ranked by effectiveness:

Move to Elasticsearch/OpenSearch — The search engine handles aggregations natively, fast. This is non-negotiable for large catalogs.
Enable "Use in Search Results Layered Navigation" instead of "Use in Layered Navigation" for attributes that don't need to show on category pages.
Limit the number of filterable attributes. 10-15 is plenty. Every extra attribute is an additional aggregation query.
Price navigation is especially expensive. The dynamic price range calculation scans the entire price index. Consider using fixed price ranges instead.
Cache the layered navigation state with a dedicated Redis cache for catalog layer data.

Price Calculation and Tier Prices

Price calculations at scale involve:

Base price, special price, tier prices, catalog rules, customer group prices, and tax rules
All computed across potentially hundreds of thousands of products
Usually during index operations but sometimes on-the-fly

For large catalogs:

Avoid complex catalog price rules. Each rule is evaluated against every applicable product during indexing. A single "Buy X get Y" rule with conditions can triple index time.
Prefer tier prices and customer group prices over catalog rules when possible. They're evaluated at the product level, not through rule logic.
Use the catalog_product_price indexer in "Schedule" mode, never "Update by Schedule" — and monitor its runtime carefully.
Consider splitting complex catalogs: base prices indexed normally, dynamic pricing handled through a custom module or PPC (Per-Price-Cache) extension.

Indexer Strategy for Large Catalogs

This is where most large-catalog Magento stores fail. Default indexer settings don't account for scale.

Critical rules:

All indexers should be "Update by Schedule" — never "Update on Save" for catalogs over 50K products.
Stagger indexer runs. Don't run all indexers simultaneously. Create a cron schedule that runs them sequentially.
Monitor indexer table sizes. The catalog_product_index_price and catalogrule_product tables grow linearly with products × customer groups × websites. At 200K products × 5 websites × 10 customer groups, you're at 10M rows.
Use the --batch-size option to control memory. Default batch is 1000; for very large catalogs, 500 may be safer to avoid memory spikes.
Consider incremental indexing where possible. Some indexers support partial reindexing based on change log tables.

Search Engine Scaling

Elasticsearch or OpenSearch is mandatory for any large Magento catalog. But even search engines need tuning.

Tips for search at scale:

Allocate enough heap. A 500K product catalog with 30 attributes indexed needs at least 8GB-16GB of JVM heap. Don't run on defaults.
Optimize mapping. Only index attributes that are actually used in search, filters, or sorting. Each indexed attribute increases index size and query time.
Use index sharding wisely. For a single Magento store, 3-5 shards per index is usually enough. Too many shards fragment the index and hurt performance.
Refresh interval matters. The default 1-second refresh interval in ES writes continuously. For Magento, 30-60 seconds is usually fine and reduces I/O pressure.
Consider a dedicated search cluster for very large catalogs (>1M products). Running ES on the same server as MySQL and PHP is a recipe for resource contention.

Database-Level Optimizations

Your MySQL configuration needs to change at scale:

Increase innodb_buffer_pool_size to 70-80% of available RAM. For a 500K product catalog with complex EAV, the working set easily reaches 8-16GB.
Enable innodb_parallel_read_threads (MySQL 8+) to parallelize EAV JOIN queries. This alone can cut category page load times by 30-40%.
Partition large tables. The catalog_product_index_price and catalogrule_product tables are excellent candidates for MySQL partitioning by website or customer group.
Monitor slow queries. Magento generates some inherently slow queries at scale. Use the MySQL slow query log to find them and consider query rewrites via plugins.
Connection pooling becomes critical. At 200+ concurrent admin + frontend users, Magento's default connection handling creates too many connections. Use a connection pooler like ProxySQL or PHP-FPM's persistent connections.

Admin Panel Performance

A large catalog doesn't just affect customers — your team suffers too. The admin product grid with 200K products is painful.

Admin-specific optimizations:

Limit the admin product grid — don't show all products by default. Set default pagination to 20 and disable "Show All" for grids.
Use admin mass actions for bulk updates instead of the product grid. Direct grid editing generates individual AJAX saves.
Create admin roles with scoped catalog access — if your team only manages a subset of products, give them filtered access.
Consider a headless admin or dedicated PIM integration for very large catalogs.

Real-World Results

Here's what a properly tuned Magento 2 store with 350K SKUs achieved:

Optimization	Before	After
Category page (anchor, 40K products)	8.2s	1.4s
Layered navigation with 12 filters	6.7s	0.9s
Price indexer runtime	47 min	12 min
Search result page	3.1s	0.6s
Admin product grid load	12s	2.3s

The key wasn't any single change — it was the combination of ES-powered navigation, sequential indexers, database tuning, and aggressive caching.

Summary Checklist

☐ Move all layered navigation to Elasticsearch/OpenSearch

☐ Set all indexers to "Update by Schedule"

☐ Stagger indexer cron jobs with different intervals

☐ Increase MySQL buffer pool to 70-80% of RAM

☐ Limit filterable attributes to 10-15

☐ Avoid complex catalog price rules

☐ Use tier prices and group prices instead

☐ Limit category depth (max 3-4 levels)

☐ Increase search engine heap allocation

☐ Tune ES/OpenSearch refresh interval to 30-60s

☐ Test flat tables vs EAV at your specific scale

☐ Monitor indexer times daily

☐ Restrict admin grid defaults

Large catalog performance isn't a single fix — it's a strategy. Start with the search engine migration, then work through the indexer and database layers. Each optimization compounds, and before you know it, that 300K catalog runs faster than your competitor's 10K one.

Magento 2 EAV Performance Deep Dive: Optimizing the Entity-Attribute-Value Model

Magevanta — Sun, 14 Jun 2026 09:02:57 +0000

The Entity-Attribute-Value (EAV) model is both Magento's greatest strength and its most persistent performance bottleneck. It gives you unlimited flexibility to add product attributes without schema changes, but that flexibility comes at a cost — every product load can spawn dozens of JOIN operations across multiple tables.

If your category pages load slowly, your product detail pages feel sluggish, or your admin product grid takes forever to filter, EAV is almost certainly a contributing factor. This guide explains exactly how the EAV model works under the hood, why it struggles at scale, and what you can do about it.

How Magento's EAV Model Works

Unlike a traditional relational model where a "product" is a single row in a products table, Magento stores product data across dozens of tables. The core EAV tables are:

catalog_product_entity — the base entity table with only the entity ID, SKU, and a few fixed columns
catalog_product_entity_{type} — separate tables for each attribute type: int, decimal, varchar, text, datetime
eav_attribute — the attribute registry defining all attributes and their metadata
catalog_product_entity_{type}_value (legacy naming) — some versions use slightly different conventions

Loading a single product with 50 attributes typically requires 10–15 JOINs across these vertical tables. For a category page listing 20 products with their names, prices, and images, Magento can execute 50–100 individual queries — before you add any layered navigation or custom logic.

Why Magento Chose EAV

Before you curse the architecture, understand why it exists. In a traditional e-commerce platform, adding a new product attribute requires an ALTER TABLE statement and a deployment. Magento merchants add hundreds of attributes through the admin panel without touching a line of SQL. The EAV model makes this possible by storing attributes as rows instead of columns.

This is great for flexibility but terrible for read-heavy workloads — and e-commerce is about as read-heavy as it gets.

The Performance Cost of EAV

Query Count Explosion

The most visible symptom of EAV overhead is query count. On a default Magento 2 installation with 50 product attributes, loading a single product detail page generates:

1 query on catalog_product_entity (the base row)
~10 queries across the value tables (one per attribute group, depending on attribute types)
1 query for the stock status
~5 queries for category associations
1 query for media gallery entries
Additional queries for tier prices, special prices, and custom options

That's 20+ queries just to load one product. For a category page with 20 products and 4 visible attributes, Magento can execute 80+ queries in the catalog product list block alone.

The JOIN Cost

EAV queries rely heavily on LEFT JOINs. Here's what a typical product load query looks like:

SELECT e.entity_id, e.sku, e.created_at,
       at_name.value AS name,
       at_price.value AS price,
       at_status.value AS status,
       at_short_description.value AS short_description
FROM catalog_product_entity AS e
LEFT JOIN catalog_product_entity_varchar AS at_name
    ON e.entity_id = at_name.entity_id
    AND at_name.attribute_id = 73
    AND at_name.store_id = 0
LEFT JOIN catalog_product_entity_decimal AS at_price
    ON e.entity_id = at_price.entity_id
    AND at_price.attribute_id = 75
    AND at_price.store_id = 0
LEFT JOIN catalog_product_entity_int AS at_status
    ON e.entity_id = at_status.entity_id
    AND at_status.attribute_id = 84
    AND at_status.store_id = 0
LEFT JOIN catalog_product_entity_text AS at_short_description
    ON e.entity_id = at_short_description.entity_id
    AND at_short_description.attribute_id = 77
    AND at_short_description.store_id = 0

Now multiply this pattern across every product on the page and every attribute you query. With a catalog of 50,000 products and 100 attributes, your value tables have 5 million rows each. LEFT JOINs on those tables without proper indexing become expensive fast.

The Store ID Factor

Every EAV value query includes a store_id condition. Magento queries for the default value first (store_id = 0), then checks for store-scoped overrides. This doubles the query load — first for the default scope, then for the specific store view.

Measuring Your EAV Performance

Before optimizing, you need to measure the current state. These approaches help you identify EAV-related bottlenecks:

1. Enable the Built-In Profiler

Magento's built-in profiler reveals the exact query count and execution time per request.

# Via env.php
'profiler' => true,

Or via app/etc/env.php set xdebug mode in the profiler configuration. For production, redirect profiler output to a log file:

// app/bootstrap.php
$_SERVER['MAGE_PROFILER'] = 'html'; // or 'csvfile' for production

2. Check the Slow Query Log

EAV performance problems nearly always show up in MySQL's slow query log. Enable it and look for queries against catalog_product_entity_* tables:

# my.cnf
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow-eav.log
long_query_time = 0.5
log_queries_not_using_indexes = 1

Queries running for 0.5+ seconds that touch EAV value tables are your optimization targets.

3. Monitor With New Relic or Blackfire

Application performance monitoring tools show you exactly which EAV queries consume the most time. Look for Magento\Eav\Model\Entity\AbstractEntity::loadAttributes() and Magento\Eav\Model\Entity\AbstractEntity::getAttribute() in your traces.

Optimization Strategies

1. Reduce Attribute Count

This is the simplest and most effective optimization. Every attribute you add to a product requires a JOIN in every product read operation.

Audit your attributes. Disable or delete attributes that aren't used anywhere — not in listings, layered navigation, product pages, exports, or attribute sets. Magento ships with hundreds of attributes out of the box, and many stores use fewer than 30% of them.

# Check which attributes are actually used
bin/magento info:cron:list  # Review attribute usage

Better yet, use a SQL query to identify unused attributes:

SELECT ea.attribute_code, ea.attribute_id,
       COUNT(cpev.entity_id) AS value_count
FROM eav_attribute AS ea
LEFT JOIN catalog_product_entity_varchar AS cpev
    ON ea.attribute_id = cpev.attribute_id
WHERE ea.entity_type_id = 4  -- product attributes
GROUP BY ea.attribute_id
HAVING value_count = 0;

Attributes with zero values across your catalog are candidates for removal.

2. Move Computed Fields to Flat Tables

For attributes that are read frequently but computed rarely (price rules applied to final prices, minimum advertised prices, etc.), consider storing computed values in a dedicated flat table instead of computing them via EAV joins.

Magento's Flat Catalog feature does exactly this — it denormalizes EAV data into a single catalog_product_flat table:

bin/magento config:set catalog/frontend/flat_catalog_product 1
bin/magento indexer:reindex catalog_product_flat

Important caveat: Flat Catalog isn't a silver bullet. It adds index maintenance overhead and can cause issues with third-party extensions. Use it selectively — enable it for stores with 50+ attributes where attribute count is the bottleneck, and test thoroughly.

For attribute sets with different profiles, flat tables use a "too many columns" strategy where unused columns are NULL. With many attribute sets, this can inflate table size dramatically.

3. Optimize EAV Table Indexing

Magento's default indexing on EAV value tables is often insufficient for large catalogs. Ensure these indexes exist:

-- Critical composite index on value tables
ALTER TABLE catalog_product_entity_varchar
    ADD INDEX `EAV_ATTR_STORE_VALUE`
    (attribute_id, store_id, entity_id);

ALTER TABLE catalog_product_entity_int
    ADD INDEX `EAV_ATTR_STORE_VALUE`
    (attribute_id, store_id, entity_id);

ALTER TABLE catalog_product_entity_decimal
    ADD INDEX `EAV_ATTR_STORE_VALUE`
    (attribute_id, store_id, entity_id);

ALTER TABLE catalog_product_entity_text
    ADD INDEX `EAV_ATTR_STORE_VALUE`
    (attribute_id, store_id, entity_id);

ALTER TABLE catalog_product_entity_datetime
    ADD INDEX `EAV_ATTR_STORE_VALUE`
    (attribute_id, store_id, entity_id);

The default Magento indexes on these tables typically only cover (entity_id) or (entity_id, attribute_id). Adding a composite index on (attribute_id, store_id, entity_id) can improve attribute-level lookups by 5-10x.

4. Tweak EAV Batch Loading

Magento's EAV model loads attributes in batches. By default, it loads all attributes for an entity type on first access. You can control this behavior:

<!-- etc/eav_attributes.xml -->
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
    <type name="Magento\Eav\Model\Entity\Attribute\Loader">
        <arguments>
            <argument name="batchSize" xsi:type="number">1000</argument>
        </arguments>
    </type>
</config>

This doesn't reduce the total work, but it prevents memory exhaustion on large entity groups.

5. Use Direct Database Reads for Critical Paths

For performance-critical code paths where you know exactly which attributes you need, bypass the EAV abstraction layer entirely:

<?php
// Instead of: $product->getName(), $product->getPrice() ...
// Use a direct read for frequently accessed attributes:

$connection = $this->resourceConnection->getConnection();
$select = $connection->select()
    ->from(['e' => 'catalog_product_entity'])
    ->joinLeft(
        ['at_name' => 'catalog_product_entity_varchar'],
        'e.entity_id = at_name.entity_id AND at_name.attribute_id = :name_attr AND at_name.store_id = :store_id',
        ['name' => 'value']
    )
    ->joinLeft(
        ['at_price' => 'catalog_product_entity_decimal'],
        'e.entity_id = at_price.entity_id AND at_price.attribute_id = :price_attr AND at_price.store_id = 0',
        ['price' => 'value']
    )
    ->where('e.entity_id IN (?)', $entityIds);

$bind = [
    'name_attr' => $this->getNameAttributeId(),
    'price_attr' => $this->getPriceAttributeId(),
    'store_id' => $this->storeManager->getStore()->getId(),
];

$products = $connection->fetchAll($select, $bind);

This pattern is especially useful for product collections in listings, sitemap generation, and export feeds where you need maximum throughput.

6. Cache Attribute Metadata

EAV attribute metadata (attribute IDs, backend types, table names) is loaded on every request and cached in Magento's cache storage. Ensure your metadata cache is working:

bin/magento cache:enable eav
bin/magento cache:clean eav

Verify the cache is populated:

redis-cli KEYS '*EAV*'  # If using Redis

If you see cache misses on EAV metadata, check that your cache backend is properly configured and has enough capacity.

7. Consider Dedicated Search Indexes

For layered navigation and product listing operations, EAV value tables are the wrong tool. This is exactly what Elasticsearch/OpenSearch excels at.

When Magento's search engine is configured, filtered attribute values are read from the search index, not from EAV tables. Ensure your layered navigation attributes are set to "Use in Search" rather than "Use in Layered Navigation" with the "Filterable (no results)" option for best performance.

# Set all layered navigation attributes to use the search engine
bin/magento config:set catalog/search/engine elasticsearch7

This moves the query burden from MySQL EAV JOINs to the search engine's inverted indexes, which handle attribute filtering natively and efficiently.

Case Study: A 60% Reduction in Product Page Load Time

I recently worked with a Magento store running 2.4.6 with 45,000 products and 120+ product attributes. Their category pages loaded in 4.2 seconds and individual product pages took 2.8 seconds.

Here's what we did:

Audited attributes: Removed 28 unused attributes (23% reduction)
Added composite indexes: On all five value tables with the (attribute_id, store_id, entity_id) pattern
Enabled Flat Catalog: For the main store view
Optimized attribute loading: For category listings, we switched to direct reads for the four attributes displayed on category pages
Ported layered navigation: Moved filtering to Elasticsearch entirely

Results:

Category page: 4.2s → 1.1s (73% improvement)
Product detail page: 2.8s → 0.9s (68% improvement)
Query count per product page: 84 → 19
Admin product grid: 8.3s → 1.7s (79% improvement)

Not every store will see this level of improvement, but the pattern holds: EAV optimization consistently delivers 40-60% reductions in page load time for stores with 50+ attributes.

EAV Anti-Patterns to Avoid

Loading All Attributes When You Need One

<?php
// BAD: Loads the entire product with all attributes
$product = $this->productRepository->get($sku);
$name = $product->getName();

// GOOD: Load only the attribute you need
$product = $this->productRepository->get($sku, false, null, true);
// The 'true' parameter enables edit mode but disables attribute pre-loading

Processing Products One at a Time

<?php
// BAD: N+1 problem — loads each product individually
foreach ($skuList as $sku) {
    $product = $this->productRepository->get($sku);
    // process...
}

// GOOD: Use a collection with selected attributes
$collection = $this->productCollectionFactory->create();
$collection->addAttributeToSelect(['name', 'price', 'sku']);
$collection->addFieldToFilter('sku', ['in' => $skuList]);

Using EAV for Read-Heavy Flows

The EAV model is optimized for write flexibility, not read speed. For any read-heavy code path — sitemaps, exports, API responses, search indexing — always batch your reads and select only the attributes you actually need.

Conclusion

The EAV model is Magento's architectural compromise between flexibility and performance. It serves a critical purpose, but it's not free. Every attribute you add increases the tax on every product read operation.

The most effective EAV performance strategy is a three-pronged approach: eliminate unused attributes, index the value tables properly, and bypass the EAV abstraction layer for performance-critical paths with direct database reads.

Start with an attribute audit — it costs nothing and often delivers the biggest gains. Add composite indexes on your value tables as a second step. Only then consider architectural changes like Flat Catalog or full search-engine migration for layered navigation.

Your mileage will vary depending on catalog size, attribute count, and server hardware, but the principles are universal: fewer attributes, better indexes, and smarter query patterns will make your Magento store noticeably faster.

Magento 2 PHP-FPM Tuning: Process Manager, Pool Configuration & Performance

Magevanta — Tue, 02 Jun 2026 09:03:06 +0000

PHP-FPM is the engine room of every Magento 2 store. Get it wrong and your perfectly-optimised Nginx, Redis, and OPcache setup still falls over under load. Get it right and you'll handle traffic spikes cleanly without throwing 502 errors or burning CPU on context-switching between hundreds of idle workers.

This guide covers everything from choosing the right process manager to calculating the optimal pm.max_children, sizing memory limits, enabling the slow-log, and verifying your changes actually stick.

Why PHP-FPM Configuration Matters for Magento

Magento is memory-hungry. A single PHP worker handling a catalog page, a checkout step, or an API call typically consumes 80–200 MB of RAM. Multiply that by every concurrent request and you quickly exceed available memory—at which point Linux starts swapping, latency explodes, and your monitoring goes red.

The PHP-FPM process manager sits between Nginx and PHP itself. It decides:

How many PHP processes run simultaneously
Whether new processes are spawned on demand or kept alive in a warm pool
How long an idle worker waits before being killed
How requests are queued when all workers are busy

Every one of those decisions directly affects Magento's response time and resource usage.

Choosing the Right Process Manager (`pm`)

PHP-FPM ships with three process manager modes: static, dynamic, and ondemand.

`pm = static`

All workers are started at boot and kept alive forever. Memory is reserved upfront—no warm-up delay for the first request, no forking overhead under load.

Best for: dedicated servers with predictable, continuous traffic. The worker count is fixed, so you need enough RAM to sustain it always.

pm = static
pm.max_children = 20

`pm = dynamic`

Workers are started on demand up to pm.max_children, but a minimum pool (pm.min_spare_servers) is kept alive so sudden bursts don't start from zero.

Best for: Magento stores with variable traffic—daytime peak, overnight lull. This is the most common production setting.

pm = dynamic
pm.max_children = 30
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 10
pm.max_requests = 500

`pm = ondemand`

Workers are created for each request and killed after pm.process_idle_timeout seconds of inactivity. Zero memory cost when idle, but cold-start latency on the first request after a quiet period.

Best for: dev environments, staging, or low-traffic stores where saving RAM matters more than latency.

Calculating `pm.max_children`

This is the most important setting. Too low → 502 errors under load. Too high → OOM kills and swap thrashing.

The formula:

pm.max_children = (Available RAM) / (Average PHP worker RSS)

Step 1 — Measure real Magento worker RSS

ps --no-headers -o rss,comm -C php-fpm | awk '{ sum += $1 } END { print sum/NR/1024 " MB avg" }'

For a typical Magento 2 store with OPcache enabled:

Storefront page: 80–120 MB
Checkout / payment: 120–160 MB
Admin panel: 150–200 MB
GraphQL / REST API: 100–140 MB

Use the 90th-percentile figure from production, not the minimum. For most Magento stores, 110–130 MB is a safe baseline.

Step 2 — Determine available RAM

Available RAM = Total RAM − OS overhead − MySQL / Redis / Varnish / Nginx memory

On a 16 GB server running only Nginx + PHP-FPM + Redis:

16384 MB
  -  512 MB  OS + system
  - 2048 MB  MySQL (innodb_buffer_pool_size + connections)
  -  512 MB  Redis
  -  128 MB  Nginx
= 13184 MB available for PHP-FPM

Step 3 — Divide

13184 / 120 ≈ 109

Round down with a 10–15 % safety margin: pm.max_children = 90

Leave headroom for memory spikes (large imports, complex cart rules, heavy admin operations).

Full Production Pool Configuration

; /etc/php/8.3/fpm/pool.d/magento.conf

[magento]
user  = www-data
group = www-data

; Socket is faster than TCP for local Nginx
listen = /run/php/php8.3-fpm-magento.sock
listen.owner = www-data
listen.group = www-data
listen.mode  = 0660

; Process manager
pm                   = dynamic
pm.max_children      = 60
pm.start_servers     = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20

; Recycle workers after N requests to prevent memory leaks
pm.max_requests = 500

; Kill a worker that has been processing for more than 60 s
request_terminate_timeout = 60s

; Slow-log: capture stack traces for requests taking > 3 s
slowlog             = /var/log/php-fpm/magento-slow.log
request_slowlog_timeout = 3s

; PHP settings override per pool
php_admin_value[memory_limit]       = 768M
php_admin_value[max_execution_time] = 600
php_admin_value[error_log]          = /var/log/php-fpm/magento-error.log
php_flag[display_errors]            = off

; Environment variables
env[MAGE_MODE]     = production
env[MAGE_RUN_TYPE] = store

Memory Limit: `768M` vs `2G`

You'll see memory_limit = 2G in many Magento "hardening" guides. That's a cargo-cult setting borrowed from import scripts. For storefront requests:

Request type	Realistic limit
Storefront page	256M
Checkout / order	512M
Admin panel general	512M
CLI / imports	2G–4G (separate pool or CLI ini)

Set memory_limit = 768M in your web pool and override with php_admin_value[memory_limit] = 4G in a dedicated CLI pool or your php.ini for php-cli. This prevents a single rogue storefront worker from consuming 2 GB while leaving other workers starved.

Separate Admin Pool (Optional but Recommended)

Admin users run heavier operations—mass attribute updates, report generation, catalogue imports, cache flushes. Give them their own pool so they never crowd out storefront workers:

; /etc/php/8.3/fpm/pool.d/magento-admin.conf

[magento-admin]
user  = www-data
group = www-data
listen = /run/php/php8.3-fpm-magento-admin.sock

pm                   = dynamic
pm.max_children      = 10
pm.start_servers     = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 4
pm.max_requests      = 100

php_admin_value[memory_limit]       = 1G
php_admin_value[max_execution_time] = 900

In Nginx, route /admin/ and /index.php/admin/ to the admin socket and everything else to the storefront socket.

location ~ ^/index\.php(/|$) {
    set $fpm_socket /run/php/php8.3-fpm-magento.sock;

    if ($request_uri ~* "^/admin") {
        set $fpm_socket /run/php/php8.3-fpm-magento-admin.sock;
    }

    fastcgi_pass  unix:$fpm_socket;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
}

Using the Slow-Log to Find Magento Bottlenecks

The PHP-FPM slow-log captures a full PHP stack trace for every request that exceeds request_slowlog_timeout. It is one of the fastest ways to spot Magento performance regressions without attaching a profiler.

Enable it (see pool config above), reproduce the slow request, then inspect:

tail -f /var/log/php-fpm/magento-slow.log

Sample output:

[02-Jun-2026 09:14:32]  [pool magento] pid 12345
script_filename = /var/www/magento/index.php
[0x00007f...] catalogProductRepository->get() /vendor/magento/module-catalog/Model/ProductRepository.php:208
[0x00007f...] \Magento\Catalog\Model\Layer\Category\ItemCollectionProvider->getCollection() ...
[0x00007f...] \Magento\LayeredNavigation\Block\Navigation::_prepareLayout() ...

The slow-log revealed layered navigation collection loading—a known hot path covered in our layered navigation performance guide.

Monitoring Pool Status

PHP-FPM exposes a /status endpoint showing active/idle workers, request queue length, and total requests served:

location ~ ^/fpm-status$ {
    allow 127.0.0.1;
    deny  all;
    fastcgi_pass unix:/run/php/php8.3-fpm-magento.sock;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

Enable in pool config:

pm.status_path = /fpm-status

Then query:

curl http://127.0.0.1/fpm-status?full

Key metrics to watch:

Metric	Warning threshold
`listen queue`	> 0 for sustained periods → increase `pm.max_children`
`active processes`	Consistently at `pm.max_children` → workers exhausted
`max active processes`	Near `pm.max_children` → approaching limit
`slow requests`	Growing fast → investigate slow-log

Plug /fpm-status into Prometheus (via php-fpm_exporter), Datadog, or New Relic for time-series alerting.

`pm.max_requests`: Preventing Memory Leaks

Magento 2 and many third-party modules are not perfectly clean: objects accumulate in memory across requests, registry entries linger, and some custom code leaks closures. Setting pm.max_requests = 500 instructs PHP-FPM to gracefully restart each worker after 500 handled requests, clearing all accumulated memory.

The trade-off is a tiny warm-up cost (OPcache re-fill for the new worker) which is negligible at max_requests = 500. For stores with lots of third-party extensions or known leak issues, drop this to 200–300.

Quick Reference Checklist

[ ] Use pm = dynamic for production Magento
[ ] Calculate pm.max_children from real RSS measurements, not guesses
[ ] Keep memory_limit ≤ 768M for web pools; use a separate high-memory pool for CLI
[ ] Enable request_terminate_timeout = 60s to kill runaway workers
[ ] Set pm.max_requests = 500 to periodically recycle workers
[ ] Enable the slow-log in staging/production for regression detection
[ ] Expose /fpm-status internally and monitor queue length + active workers
[ ] Create a separate admin pool with lower pm.max_children and higher memory/time limits
[ ] Prefer Unix sockets over TCP for Nginx ↔ PHP-FPM on the same host

Verifying Configuration

After editing pool files, always validate before reloading:

php-fpm8.3 -t             # syntax check
systemctl reload php8.3-fpm

# Confirm workers started
ps aux | grep php-fpm | wc -l

# Watch status under a load test
watch -n1 "curl -s http://127.0.0.1/fpm-status | grep -E 'active|idle|queue'"

Use ab (Apache Bench) or wrk for a quick load test:

wrk -t4 -c50 -d30s https://yourstore.com/

Watch the FPM status during the test. If listen queue climbs above 0, you need more workers (more RAM) or faster PHP execution (profiling, caching, fewer plugins).

PHP-FPM tuning is not a one-and-done task. As your Magento store grows—more SKUs, more extensions, higher traffic—revisit pm.max_children quarterly and after major upgrades. The fifteen minutes it takes to recalculate and re-tune pays for itself the first time you dodge a traffic-spike outage.

Magento 2 Third-Party Extension Performance Audit: Find and Fix Hidden Bottlenecks

Magevanta — Mon, 01 Jun 2026 09:03:06 +0000

Third-party extensions are a double-edged sword. They add capabilities that would take months to build in-house, but every additional module adds plugins, observers, layout blocks, and database queries to every page load. A store with 40 extensions installed could easily have 200+ extra interceptors firing on a single request — and most developers have no idea which ones are costing them.

This guide walks you through a systematic performance audit of your extension stack: how to measure the real cost of each module, what patterns cause the most damage, and how to fix (or quarantine) the worst offenders.

Why Extensions Are the #1 Performance Culprit

Before blaming infrastructure, consider that Magento's plugin (interceptor) system means any third-party module can silently wrap any public method in the entire core. When you install 10 extensions, each with 5–15 plugins, you can easily end up with:

100+ interceptors compiled into generated code
Additional database queries per request (EAV attribute loads, config reads, custom tables)
Extra layout XML blocks rendering widgets or tracking scripts
Observers attached to frequently-fired events like sales_quote_collect_totals_before

The worst part: these costs accumulate invisibly. No single extension looks bad in isolation, but together they drag TTFBs from 200ms to 2+ seconds.

Step 1: Baseline Your Current State

Before auditing anything, establish a baseline. You need hard numbers to compare against.

# Enable built-in profiler
php bin/magento dev:query-log:enable
php bin/magento cache:clean

Use a simple shell script to benchmark a representative page:

for i in {1..5}; do
  curl -s -o /dev/null -w "%{time_total}\n" \
    "https://yourstore.com/some-product.html"
done

Record your median response time for:

Homepage
Category page (with layered nav)
Product page
Checkout cart page

Also grab a database query count baseline from var/log/db.log or your APM tool. Knowing you're at 180 queries per page before the audit gives you something to beat.

Step 2: List Every Installed Extension

Get a clean list of all non-Magento modules:

php bin/magento module:status --enabled | grep -v "^Magento_" | grep -v "^List" | grep -v "^-"

For each module, note:

Vendor name and version
Last update date (stale = red flag)
Purpose (payment, shipping, analytics, CMS, etc.)
Whether it's business-critical or optional

Modules that haven't been updated in 2+ years deserve extra scrutiny. They often rely on deprecated APIs and haven't been optimized for modern PHP or Magento versions.

Step 3: Profile with Blackfire or the Built-in Profiler

The fastest way to see which extensions are expensive is to profile a real request.

Option A: Blackfire.io (Recommended)

Install the Blackfire agent and PHP probe on your staging server. Then:

blackfire curl https://yourstore.com/catalog/category/view/id/42

In the Blackfire UI, expand the call tree and look for:

Any vendor namespace taking >5% of wall time
Deep interceptor chains (Plugin > Plugin > Plugin...)
Repeated identical DB queries triggered from observers

Option B: Magento Built-in Profiler

Enable the Magento profiler in env.php:

'profiler' => [
    'class' => '\Magento\Framework\Profiler\Driver\Standard',
    'output' => 'html'
]

Or via env variable:

MAGE_PROFILER=html php -S localhost:8080 -t pub/ pub/index.php

This outputs a timing table at the bottom of each page showing which blocks, layouts, and observers are slow. It's less granular than Blackfire but zero-cost.

Option C: New Relic APM

If you have New Relic, filter transactions by slowest segments and expand to the code-level trace. Extension methods show up with their full class path, making identification trivial.

Step 4: Identify the Worst Offenders

After profiling, patterns to look for:

4.1 Plugin Chains on Critical Methods

Expensive plugin chains almost always appear on:

Magento\Catalog\Model\Product::getPrice
Magento\Quote\Model\Quote\Item\AbstractItem::calcRowTotal
Magento\Checkout\Model\Session::getQuote

If 3–4 extensions each add an around plugin to getPrice, the interception overhead compounds. Check generated/code/ for long plugin chains:

# Count plugins on a specific class
grep -r "aroundGetPrice\|beforeGetPrice\|afterGetPrice" generated/code/ | wc -l

More than 5–6 plugins on the same method is a warning sign.

4.2 Observer Storms on Quote Events

The worst offenders are often marketing/analytics extensions that attach to sales_quote_collect_totals_*, checkout_cart_product_add_after, or catalog_product_load_after. These events fire multiple times per request on the cart page.

Find all observers:

grep -r "<event name=" vendor/*/*/etc/events.xml app/code/*/etc/events.xml 2>/dev/null \
  | grep -v "Magento" \
  | awk -F: '{print $1}' | sort | uniq -c | sort -rn | head -20

This shows you which modules register the most event observers across the board.

4.3 Layout Block Injection on Every Page

Some extensions inject blocks into the default layout handle, meaning their block is instantiated on every page even if it doesn't render anything visible:

grep -r "<handle name=\"default\"" vendor/ app/code/ 2>/dev/null \
  | grep -v "Magento" | head -20

Even a block that renders nothing still triggers __construct, config reads, and occasionally DI-heavy factory calls.

4.4 Config Scoped Reads Without Cache

Look for extensions calling Magento\Framework\App\Config\ScopeConfigInterface::getValue in hot paths without memoization. Every uncached config read hits the config layer.

# Rough count of config reads per vendor
grep -r "scopeConfig->getValue" vendor/ \
  | grep -v "Magento/" \
  | awk -F/ '{print $2}' | sort | uniq -c | sort -rn | head -10

Step 5: Fix Strategies

5.1 Disable Non-Essential Modules for Testing

The fastest way to validate an extension is causing slowdown: disable it and retest.

php bin/magento module:disable Vendor_ModuleName
php bin/magento cache:flush
# benchmark again

If response time drops by >10% with a single module disabled, you've found a major culprit. You can then decide whether to:

Replace it with a lighter alternative
Optimize the specific slow path
Keep it but confine its scope

5.2 Replace `around` Plugins with `before`/`after`

If you control the extension code, around plugins are the most expensive interceptor type — they wrap the entire original method and prevent call chain optimizations. Wherever possible, convert to before or after:

// Instead of this:
public function aroundGetPrice(
    \Magento\Catalog\Model\Product $subject,
    callable $proceed
): float {
    $price = $proceed();
    return $price * $this->getMultiplier();
}

// Do this:
public function afterGetPrice(
    \Magento\Catalog\Model\Product $subject,
    float $result
): float {
    return $result * $this->getMultiplier();
}

This is especially impactful when the plugin fires in a loop (e.g., iterating over cart items).

5.3 Add Memoization to Repeated Method Calls

Many extensions calculate the same value (a config flag, a customer group check) dozens of times per request without caching the result:

class MyPlugin
{
    private ?bool $isEnabled = null;

    public function afterGetPrice(Product $subject, float $result): float
    {
        if ($this->isEnabled === null) {
            $this->isEnabled = $this->scopeConfig->isSetFlag('vendor/module/enabled');
        }
        if (!$this->isEnabled) {
            return $result;
        }
        // ... expensive logic
        return $result;
    }
}

Add a private ?type $cached = null; pattern to any value read inside a frequently-called plugin or observer.

5.4 Move Heavy Logic to Async or Cron

Analytics tracking, loyalty point calculations, and marketing syncs don't need to happen during the customer's request. Push them to a message queue:

// Instead of direct processing in observer:
public function execute(\Magento\Framework\Event\Observer $observer): void
{
    $this->messageQueue->publish('vendor.analytics.track', [
        'event' => 'product_view',
        'product_id' => $observer->getProduct()->getId(),
        'customer_id' => $this->customerSession->getCustomerId(),
    ]);
}

The queue consumer handles it asynchronously, keeping the customer-facing request lean.

5.5 Scope Layout XML to Specific Handles

If an extension's block only makes sense on the cart page, restrict it to the checkout_cart_index layout handle — not default:

<!-- vendor/Module/view/frontend/layout/checkout_cart_index.xml -->
<page xmlns:xsi="..." xsi:noNamespaceSchemaLocation="...">
    <body>
        <referenceContainer name="content">
            <block class="Vendor\Module\Block\Widget" name="vendor_widget"/>
        </referenceContainer>
    </body>
</page>

This alone can shave 10–30ms on every non-cart page.

Step 6: Ongoing Monitoring

A one-time audit isn't enough — extensions get updated, new ones get installed, and performance regressions creep in silently. Build these habits:

Benchmark on every deploy. Add a simple curl-based response time check to your CI pipeline. Alert if median TTFB increases by more than 15% on key pages.

Review the generated interceptor file on each module install. After php bin/magento setup:di:compile, check what's new in generated/code/Magento/ for your most critical classes.

Audit before you install. Before adding any extension from the Marketplace, check:

How many plugins does it register? (grep -r "type name=" etc/di.xml)
Does it modify high-traffic events?
Is it actively maintained?

Quick Reference: Audit Checklist

Check	Tool	Red Flag
Response time baseline	curl / wrk	>500ms TTFB on product page
Plugin count per critical class	grep generated/	>6 plugins on same method
Observer count per event	grep events.xml	>3 observers on quote events
Default layout injection	grep layout XML	Any non-Magento block in default
Stale extensions	composer show	Last update >2 years ago
DB queries per page	query log / Blackfire	>150 queries on category page

Wrapping Up

Third-party extension audits aren't glamorous, but they're often the highest-ROI performance work you can do on an established Magento 2 store. A single badly-written analytics plugin wrapping a core method can cost you 300ms per request across your entire catalog.

The process is straightforward: baseline, profile, identify, fix, and monitor. Start with your five slowest pages, trace the top three timing contributors in each, and work down the list. You'll likely find that 20% of your extensions are causing 80% of your extension-related overhead — and most of those issues have clean, targeted solutions.

Combine this audit with Magento's built-in profiling, Blackfire, or New Relic, and you'll have the data to make confident decisions about which extensions earn their place on your store.

Magento 2 Profiling & Performance Debugging: Find Bottlenecks Fast

Magevanta — Fri, 29 May 2026 09:02:46 +0000

Performance issues in Magento 2 are rarely obvious. A page that takes 4 seconds might be suffering from a single misconfigured plugin, a runaway EAV query, or a third-party module making 200 redundant cache reads. Without proper profiling tools, you're flying blind — guessing, commenting out code, and hoping for the best.

This guide walks through the full profiling toolkit for Magento 2: from quick built-in options to professional-grade APM tools like Blackfire and New Relic. You'll learn what to use, when to use it, and how to interpret the results.

Why Generic Profiling Isn't Enough

Magento 2 is a complex, event-driven framework with hundreds of plugins, observers, and DI-compiled classes running on every request. A standard PHP profiler shows you call stacks, but doesn't give context about why something is slow.

You need tools that understand:

The plugin/interceptor chain
DI container overhead
MySQL query patterns (N+1, full scans)
Cache hit/miss ratios
Layout XML parsing and block rendering

Let's start simple and work up to the heavy artillery.

1. Magento's Built-in Profiler

Magento ships with a lightweight built-in profiler you can enable without any extra tooling. It's ideal for quick debugging in local and staging environments.

Enable via environment variable

# In your .htaccess or nginx config
MAGE_PROFILER=html

# Or via pub/index.php temporarily
$_SERVER['MAGE_PROFILER'] = 'html';

Or set it in app/etc/env.php:

'x-frame-options' => 'SAMEORIGIN',
'MAGE_MODE' => 'developer',
'dev' => [
    'profiler' => '1'
],

Once enabled, a profiler table appears at the bottom of each page showing timer blocks, nesting levels, and call counts. Look for:

Blocks with high "Avg" time and low call counts (expensive single operations)
Blocks called hundreds of times (loop inefficiency or plugin waterfalls)

Custom profiler blocks in your own code

use Magento\Framework\Profiler;

Profiler::start('my_custom_operation');
// ... your code
Profiler::stop('my_custom_operation');

This is great for benchmarking specific methods during development without a full APM setup.

2. MySQL Query Logging

Slow queries are the most common bottleneck in Magento. Enable MySQL slow query logging to capture them:

-- In MySQL session or my.cnf
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.5;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
SET GLOBAL log_queries_not_using_indexes = 'ON';

Then analyze with mysqldumpslow or pt-query-digest:

# Group by query pattern, sort by total time
pt-query-digest /var/log/mysql/slow.log --limit 20

Magento's query log via Varien_Db

In developer mode, you can also log all queries Magento executes. Or use a custom plugin on Magento\Framework\DB\Adapter\Pdo\Mysql::query() to log slow queries with their origin (class + method).

Spotting N+1 patterns

The classic N+1 problem in Magento looks like this in your logs:

SELECT * FROM catalog_product_entity WHERE entity_id = 42
SELECT * FROM catalog_product_entity WHERE entity_id = 43
SELECT * FROM catalog_product_entity WHERE entity_id = 44
... (200 more)

Fix: use addAttributeToSelect('*') on collections and load them in bulk, or leverage the product repository with proper filtering.

3. Blackfire.io — The Gold Standard

Blackfire is the professional choice for PHP profiling. It integrates natively with Magento 2 and produces call graphs that reveal exactly where time and memory are spent.

Installation

# Install Blackfire PHP extension
curl -sS https://packages.blackfire.io/gpg.key | sudo apt-key add -
echo "deb http://packages.blackfire.io/debian any main" | sudo tee /etc/apt/sources.list.d/blackfire.list
sudo apt-get update && sudo apt-get install blackfire-php blackfire

# Configure credentials
blackfire agent:config

Add to your php.ini:

extension=blackfire.so
blackfire.agent_socket=tcp://127.0.0.1:8307

Profile a page

blackfire curl https://yourstore.local/catalog/category/view/id/5

Or use the browser extension for GUI-driven profiling with comparison between runs.

Reading the call graph

Blackfire generates an interactive flame graph. Key metrics to watch:

Metric	What it means
Wall time	Real elapsed time
CPU time	Processing time (excludes I/O waits)
I/O time	Disk/network waits (usually DB or cache)
Memory	Peak memory per call
Calls	How many times a function was invoked

Focus on nodes with high exclusive time (time spent in that function itself, not its children). A function called 1,000 times with 0.1ms each adds up to 100ms — often invisible until you see the call count.

Blackfire builds & assertions

For CI/CD pipelines, define performance budgets:

# .blackfire.yaml
tests:
  "Homepage must be fast":
    path: /
    assertions:
      - "main.wall_time < 800ms"
      - "metrics.sql.queries.count < 30"
      - "metrics.cache.read.count < 100"

This fails the build if the homepage regresses beyond your defined thresholds.

4. New Relic APM

New Relic is better suited for production monitoring and long-term trend analysis. Where Blackfire is surgical (profile this specific request), New Relic is epidemiological (what's slow across thousands of requests).

Install the PHP agent

curl -L https://download.newrelic.com/php_agent/release/newrelic-php5-*.tar.gz | tar -xz
sudo ./newrelic-install install

Configure in newrelic.ini:

newrelic.appname = "Magento Production"
newrelic.license = "YOUR_LICENSE_KEY"
newrelic.transaction_tracer.enabled = true
newrelic.transaction_tracer.threshold = 500ms
newrelic.slow_sql.enabled = true

What to watch in New Relic

Transaction traces — drill into the slowest requests over time. New Relic shows the full call stack including DB queries, external calls, and cache operations.

Apdex score — a customer satisfaction metric. Target > 0.9 for Magento stores. Anything below 0.7 needs immediate attention.

Database tab — shows the slowest SQL queries across all transactions, with execution plans and call frequency.

Custom attributes — add Magento-specific context:

if (extension_loaded('newrelic')) {
    newrelic_add_custom_parameter('customer_group', $customerGroup);
    newrelic_add_custom_parameter('store_id', $storeId);
    newrelic_add_custom_parameter('cache_hit', $cacheHit ? 'yes' : 'no');
}

5. Tideways — APM Built for PHP Frameworks

Tideways is worth mentioning as a Magento-aware alternative to New Relic. It understands Magento's MVC structure and groups transactions by controller action automatically. Setup is similar to Blackfire — install the PHP extension, configure credentials, and it starts collecting data passively.

6. The Xdebug + KCachegrind Combo (Local Only)

For deep local debugging, Xdebug's profiling mode generates Cachegrind files visualizable with KCachegrind or QCachegrind:

; php.ini
xdebug.mode = profile
xdebug.output_dir = /tmp/xdebug
xdebug.profiler_output_name = cachegrind.out.%t.%p

Trigger with: ?XDEBUG_PROFILE=1 on a request URL.

Open the .cachegrind file in KCachegrind to see a full call tree with inclusive/exclusive times.

⚠️ Never enable Xdebug profiling in production — it adds massive overhead and generates large files.

Practical Debugging Workflow

Here's a proven workflow when a Magento page is suddenly slow:

Check obvious causes first — deployment recently? New module? Config cache cleared?
Enable MySQL slow query log and check for expensive queries
Blackfire profile the slow page — look at exclusive times > 50ms
Check the plugin chain on hot paths (e.g., catalog_product_load_after observers)
Profile again with the fix — compare Blackfire runs side by side
Add a Blackfire assertion to prevent regression

Quick wins to check first

Before deep profiling, verify these common culprits:

# Check OPcache is enabled and warm
php -r "var_dump(opcache_get_status()['opcache_enabled']);"

# Check Redis connectivity and hit ratio
redis-cli INFO stats | grep keyspace

# Check if Magento caches are enabled
bin/magento cache:status

# Check for runaway cron jobs
bin/magento cron:status

Profiling in CI/CD

Automate performance regression detection with Blackfire in your pipeline:

# GitHub Actions example
- name: Run Blackfire performance tests
  run: |
    blackfire curl --json https://staging.yourstore.com/ \
      --assert "main.wall_time < 1s"

This prevents performance regressions from reaching production undetected — the same way unit tests prevent functional regressions.

Summary

Tool	Best for	Environment
Built-in Profiler	Quick timer blocks	Dev/staging
MySQL slow log	Query-level analysis	All
Blackfire	Surgical code profiling	Dev/staging/CI
New Relic	Production monitoring	Production
Xdebug + KCachegrind	Deep call graph analysis	Dev only

Profiling is a skill that compounds over time. The more you profile, the faster you'll spot patterns — that suspicious 300ms block in Magento\Catalog\Model\ResourceModel\Product\Collection::load, the plugin interceptor chain that fires 40 times per request, or the layout XML file that parses 200KB of XML on every uncached page load.

Start with the built-in profiler and MySQL logs. Graduate to Blackfire when you need precision. Use New Relic in production to catch what you missed. And always — always — profile before and after any optimization to prove it actually helped.

Magento 2 Static Content Deploy Optimization: Faster Builds, Fewer Headaches

Magevanta — Thu, 28 May 2026 09:02:32 +0000

Static content deployment is one of the most time-consuming steps in a Magento 2 release pipeline. On a large store with multiple themes, locales, and hundreds of modules, setup:static-content:deploy can take anywhere from five minutes to over thirty. That's thirty minutes of downtime risk, blocked deployments, and frustrated developers staring at a progress bar.

This guide covers every lever available to you: parallelization, scoped deploys, strategy selection, content versioning, and how to integrate all of this into a zero-downtime CI/CD pipeline.

Why Static Content Deploy Is Slow

Before optimizing, understand the problem. When you run bin/magento setup:static-content:deploy, Magento does the following for every theme/locale combination:

Resolves all Less/CSS source files, compiling them with the configured strategy
Copies or symlinks JavaScript, images, and fonts from modules and themes
Generates RequireJS configuration files
Applies translations to JS files per locale
Publishes everything to pub/static/

On a store with 3 themes × 5 locales, that's 15 combinations — each requiring full resolution of the entire asset tree. Add 200+ modules and you start to understand why it takes so long.

1. Parallelize With `-j`

The single most impactful flag is -j (jobs), which controls parallelism:

bin/magento setup:static-content:deploy -f -j 4

By default, Magento deploys each theme/locale combination sequentially. With -j 4, it runs four processes in parallel. Set this to the number of available CPU cores — or slightly above for I/O-bound operations:

# Detect CPU count and use it
CORES=$(nproc 2>/dev/null || sysctl -n hw.ncpu 2>/dev/null || echo 4)
bin/magento setup:static-content:deploy -f -j $CORES

On a 4-core server this alone can cut deploy time by 60-70%. On 8 cores, the gains compound further.

Caution: Don't blindly set -j 16 on a 4-core server. You'll swap memory and end up slower. Match cores to available resources.

2. Scope Your Deploy: Only What You Need

Deploying every theme and locale is wasteful if your store only uses a subset. Scope it explicitly:

bin/magento setup:static-content:deploy \
  -f \
  -j 4 \
  --theme Magento/luma \
  --theme Vendor/custom-theme \
  nl_BE en_US fr_BE

Pass themes with --theme and list locales as space-separated arguments at the end. This is dramatically faster than the default "everything" approach.

Pro tip: Define these in a deploy script variable so they're centrally maintained:

THEMES="--theme Vendor/custom-theme --theme Magento/backend"
LOCALES="nl_BE en_US fr_BE de_DE"

bin/magento setup:static-content:deploy -f -j 4 $THEMES $LOCALES

Never include Magento/blank in production deploys unless a theme directly extends it without adding any customizations — even then, the admin theme covers most of its use cases.

3. Choose the Right Deploy Strategy

Magento offers three static content deploy strategies, configurable via --strategy:

`quick` (default since 2.3)

bin/magento setup:static-content:deploy --strategy=quick

Deploys files once and symlinks duplicates. Fast, low disk usage. Best for most production stores.

`compact`

bin/magento setup:static-content:deploy --strategy=compact

Similar to quick but with a slightly different deduplication approach. Marginally slower but produces smaller output on disk. Use it when disk space is constrained.

`standard`

bin/magento setup:static-content:deploy --strategy=standard

Copies every file for every theme/locale combination without deduplication. Produces the largest output but is the most compatible. Only use this if you're seeing symlink-related issues with quick.

For 99% of stores, quick is the right choice. If you're still on the standard default, switching to quick alone can cut deploy time significantly.

4. Use `--no-html-minify` During Development

HTML minification of static templates adds time with minimal benefit in development contexts. Skip it:

bin/magento setup:static-content:deploy -f --no-html-minify

In production you want minification, but for staging pipelines where you're iterating on deploys, skipping it saves time.

5. Deploy Admin Separately

The Magento admin (Magento/backend) has its own asset tree. In a pipeline with a custom frontend theme, deploying admin and frontend in sequence wastes time. Structure it to run in parallel:

# Run both in parallel background processes
bin/magento setup:static-content:deploy -f -j 2 \
  --theme Vendor/custom-theme nl_BE en_US fr_BE &

bin/magento setup:static-content:deploy -f -j 2 \
  --theme Magento/backend en_US &

wait
echo "Both deploys complete"

This lets your CI server use all cores across both operations simultaneously.

6. Content Versioning Strategy

Every static content deploy generates a new version ID, which busts the browser cache. This is good for cache invalidation but means users re-download all assets after every deploy — even if nothing changed.

Check the current version:

cat pub/static/deployed_version.txt

For deployments where static assets haven't changed, you can preserve the existing version:

# Only redeploy if source files changed
if git diff HEAD~1 --name-only | grep -qE '(view/|web/|layout/)'; then
  bin/magento setup:static-content:deploy -f -j 4 $THEMES $LOCALES
else
  echo "No static asset changes — skipping deploy"
fi

This is powerful in trunk-based development where most commits are backend-only.

7. Warm `pub/static` Before Cutting Traffic

Never cut traffic to a new release before static content is deployed. Structure your pipeline correctly:

# 1. Deploy code
git pull origin main

# 2. Run database upgrades (maintenance mode on)
bin/magento maintenance:enable
bin/magento setup:upgrade --keep-generated

# 3. Deploy static content (maintenance still on)
bin/magento setup:static-content:deploy -f -j 4 $THEMES $LOCALES

# 4. Compile DI
bin/magento setup:di:compile

# 5. Disable maintenance and flush cache
bin/magento maintenance:disable
bin/magento cache:flush

The key insight: setup:static-content:deploy writes to pub/static/ which is served directly by nginx. As soon as the files are there, they're live — even before maintenance mode is disabled. This means your CDN/Varnish can start warming the new assets while the site is still in maintenance.

8. Symlink Mode for Development

On local development environments, deploying static content on every change is a workflow killer. Switch to developer mode:

bin/magento deploy:mode:set developer

In developer mode, Magento resolves static assets on-the-fly using symlinks into module view/ directories. No deploy step needed after every Less change. Use grunt watch or the built-in Less compiler to compile CSS automatically.

For a middle ground on staging — faster than full deploy but closer to production — use:

bin/magento deploy:mode:set default
bin/magento setup:static-content:deploy -f --symlink-locale $THEMES $LOCALES

9. CI/CD Integration: Build Once, Distribute Many

If your CI pipeline deploys to multiple identical servers (horizontal scaling), you don't need to run setup:static-content:deploy on each one. Run it once, tar the output, and distribute:

# On build server
bin/magento setup:static-content:deploy -f -j 8 $THEMES $LOCALES
tar -czf static-content-$(git rev-parse --short HEAD).tar.gz pub/static/

# On each web server
tar -xzf static-content-${GIT_SHA}.tar.gz

This approach:

Ensures all servers have identical static content (no race conditions)
Cuts total deploy time proportional to the number of web servers
Allows content to be pre-warmed before servers receive traffic

Store the tarball in your artifact repository (S3, GitHub Packages, Artifactory) with the commit SHA as the identifier. If a rollback is needed, fetch the previous artifact rather than rerunning the deploy.

10. Monitor Deploy Times

Track setup:static-content:deploy duration over time. A sudden spike usually signals:

A new module with a large web/ directory
A Less compilation error causing retries
An accidental addition of an extra locale
Disk I/O saturation on the build server

Add timing to your deploy scripts:

START=$(date +%s)
bin/magento setup:static-content:deploy -f -j 4 $THEMES $LOCALES
END=$(date +%s)
echo "Static deploy took $((END - START))s"

Feed these metrics into your monitoring system (Datadog, Grafana, or even a simple log file) so you can correlate deploy time growth with specific releases.

Benchmark: What to Expect

Here's a rough guide for a mid-sized store (2 themes, 3 locales, ~200 modules):

Configuration	Approximate Time
Default (sequential, standard strategy)	18–25 min
`-j 4`, `quick` strategy	6–9 min
`-j 8`, scoped locales, `quick`	3–5 min
Distributed build (tarball)	< 1 min per server

The gains from parallelization and strategy selection are real and significant. There's no reason to accept a 20-minute deploy window when the same output can be generated in under five.

Key Takeaways

Static content deployment doesn't have to be the bottleneck it is for most teams. The biggest wins:

Use -j with your core count — this alone is transformative
Scope themes and locales — don't deploy what you don't use
Use quick strategy — it's the default for a reason, but many older stores still run standard
Separate admin from frontend and run them in parallel
Build once, distribute many in horizontally-scaled environments
Skip redeploys when static assets haven't changed

Apply these together and your 20-minute deploy window shrinks to under five minutes — leaving more time for shipping features instead of waiting on build pipelines.

Magento 2 Nginx Optimization for High Traffic — Complete Server Tuning Guide

Magevanta — Wed, 27 May 2026 09:02:49 +0000

Your Magento store can have perfect PHP-FPM pools, well-tuned Redis, and optimized MySQL — and still buckle under load because Nginx is configured with defaults meant for a blog, not an ecommerce platform. Nginx is the front door to your entire stack. If it's slow, everything behind it is slow.

This guide walks through every lever worth pulling: connection handling, compression, caching headers, microcaching, SSL/TLS, and real-world configs for a Magento 2 production server.

Why Nginx Defaults Aren't Enough

Out-of-the-box Nginx ships with conservative defaults:

worker_processes 1 — single worker, ignoring your CPU cores
No gzip compression enabled
Keepalive timeouts that force reconnects
No browser cache headers
TLS handshakes that repeat work they don't need to

For a low-traffic site this doesn't matter. For Magento — which serves category pages, product pages, checkout flows, and API calls simultaneously — these defaults become bottlenecks at a few hundred concurrent users.

1. Worker Processes and Connections

Start at the top of nginx.conf:

worker_processes auto;
worker_rlimit_nofile 65535;

events {
    worker_connections 4096;
    use epoll;
    multi_accept on;
}

worker_processes auto — Nginx will match the number of workers to available CPU cores. A 4-core server gets 4 workers.

worker_rlimit_nofile 65535 — raises the OS file descriptor limit per worker. Each active connection uses a file descriptor; the default of 1024 is dangerously low for production.

worker_connections 4096 — maximum connections per worker. Total concurrent connections = worker_processes × worker_connections. On a 4-core server: 16,384 concurrent connections max.

use epoll — Linux-only but highly efficient; scales better than select or poll under thousands of connections.

multi_accept on — workers accept all pending connections at once instead of one at a time.

2. Gzip Compression

Magento pages are large: HTML pages often exceed 100KB before JS and CSS. Gzip cuts transfer sizes by 60–80%:

http {
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 5;
    gzip_min_length 1000;
    gzip_types
        text/plain
        text/css
        text/xml
        text/javascript
        application/javascript
        application/x-javascript
        application/json
        application/xml
        application/xml+rss
        application/vnd.ms-fontobject
        font/eot
        font/otf
        font/ttf
        image/svg+xml;
}

gzip_comp_level 5 — the sweet spot. Level 9 uses ~30% more CPU for only ~2% better compression. Level 5 is fast and effective.

gzip_vary on — adds a Vary: Accept-Encoding header so CDNs and proxies serve the right version to each client.

gzip_min_length 1000 — don't bother compressing tiny responses; overhead outweighs benefit below ~1KB.

3. Keepalive and Timeouts

Keepalive connections let the browser reuse TCP connections for multiple requests, eliminating repeated TCP handshakes:

http {
    keepalive_timeout 65;
    keepalive_requests 100;

    # Upstream keepalive to PHP-FPM
    upstream fastcgi_backend {
        server unix:/run/php/php8.3-fpm.sock;
        keepalive 32;
    }
}

keepalive_timeout 65 — hold connections open for 65 seconds. Fine for most workloads; reduce to 15–30 on memory-constrained servers.

keepalive 32 in the upstream block — keeps up to 32 persistent connections open to PHP-FPM, avoiding socket overhead on every PHP request.

Also tune these to avoid slow clients tying up workers:

client_header_timeout 15;
client_body_timeout  15;
send_timeout         15;
reset_timedout_connection on;

4. Browser Cache Headers for Static Assets

Magento's static files (JS, CSS, images, fonts) are versioned via deploy version hashes. Set aggressive caching:

location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot|webp)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
    access_log off;
}

immutable tells supporting browsers (Chrome, Firefox) to never re-validate the file during its lifetime — eliminating conditional GET requests entirely.

access_log off for static assets reduces disk I/O significantly on busy servers.

5. Microcaching with FastCGI Cache

Full Page Cache (Varnish or Magento built-in) handles authenticated sessions poorly by design. Microcaching fills the gap: cache PHP responses for just 1–5 seconds. At 500 req/s, a 1-second cache reduces PHP hits by ~99% for repeated URLs.

Define a cache zone in nginx.conf:

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=MAGENTO:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

In your server block:

set $no_cache 0;

# Don't cache POST requests
if ($request_method = POST) { set $no_cache 1; }

# Don't cache if session cookie present (logged-in users, active cart)
if ($http_cookie ~* "(PHPSESSID|frontend|adminhtml|checkout)") {
    set $no_cache 1;
}

location ~ \.php$ {
    fastcgi_cache MAGENTO;
    fastcgi_cache_valid 200 1s;
    fastcgi_cache_bypass $no_cache;
    fastcgi_no_cache $no_cache;
    add_header X-FastCGI-Cache $upstream_cache_status;

    include fastcgi_params;
    fastcgi_pass fastcgi_backend;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

The X-FastCGI-Cache header lets you verify HIT/MISS/BYPASS in response headers — essential for debugging. If you see BYPASS on every request, check that your cookie exclusions are correct.

Important: Do not use microcaching in place of proper FPC. Use it as a complement for high-burst traffic windows (flash sales, launches).

6. SSL/TLS Performance

TLS termination at Nginx is unavoidable on HTTPS-only stores. Tune it to minimize handshake overhead:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers on;

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;  # Disable for perfect forward secrecy

ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;

ssl_session_cache shared:SSL:10m — a 10MB shared cache holds ~40,000 sessions, allowing TLS resumption (no full handshake for returning visitors).

OCSP stapling (ssl_stapling on) — Nginx fetches and caches the certificate validity check, so your clients don't have to. Eliminates one round-trip per new connection.

TLSv1.3 — if you can drop TLSv1.2 entirely (verify your CDN and payment providers support it), TLSv1.3 does a full handshake in 1 round trip vs. 2.

7. Buffer Tuning

Large Magento responses (admin grids, product list pages) benefit from proper buffer settings:

client_body_buffer_size 128k;
client_max_body_size    64m;   # Required for media imports

proxy_buffer_size          4k;
proxy_buffers            4 32k;
proxy_busy_buffers_size  64k;

fastcgi_buffers          16 16k;
fastcgi_buffer_size      32k;

fastcgi_buffers 16 16k — 256KB total buffer per request. Enough for most Magento pages without disk buffering.

If a page exceeds fastcgi_buffers, Nginx writes the overflow to a temp file — adding disk I/O to every large response. Set this high enough to avoid it.

8. Rate Limiting for Admin and API

Protect your admin panel and REST API from brute-force and abuse:

# Define zones in http block
limit_req_zone $binary_remote_addr zone=admin:10m rate=5r/s;
limit_req_zone $binary_remote_addr zone=api:10m rate=30r/s;

# Apply in server block
location /admin {
    limit_req zone=admin burst=10 nodelay;
    # ... rest of config
}

location /rest {
    limit_req zone=api burst=50 nodelay;
    # ... rest of config
}

burst allows short spikes above the rate. nodelay processes burst requests immediately instead of queuing them — important for API clients that batch requests.

9. Monitoring What You've Done

After applying changes, verify with:

# Test config before reloading
nginx -t

# Reload without dropping connections
nginx -s reload

# Watch real-time connection states
ss -s

# Check cache hit rate (tail access log with cache status)
tail -f /var/log/nginx/access.log | grep 'X-Cache'

Use ab (ApacheBench) or wrk for quick load tests before and after:

# 1000 requests, 50 concurrent
ab -n 1000 -c 50 https://your-store.com/

Putting It All Together

Nginx optimization is one of the highest-leverage things you can do for a Magento store: it affects every single request before PHP even runs. The changes above — workers, gzip, keepalive, browser cache, microcaching, TLS tuning, and buffers — consistently yield 2–4× improvement in requests-per-second capacity on the same hardware.

Start with worker_processes auto and gzip (both zero-risk changes), then profile with a load test before adding microcaching, which requires careful cookie exclusion to avoid caching user-specific content.

The full picture: Nginx handles connections and serves static files; Varnish or Magento FPC serves full pages; Redis caches sessions and blocks; PHP-FPM processes what's left. Each layer does its job. Nginx's job is to be fast and efficient at the very edge — don't let defaults undermine the rest of your stack.

Magento 2 B2B Performance Optimization: Shared Catalogs, Quotes & Company Accounts

Magevanta — Tue, 26 May 2026 09:03:16 +0000

Adobe Commerce B2B unlocks powerful functionality for wholesale and enterprise merchants — company accounts, shared catalogs, negotiable quotes, quick order, and requisition lists. But these features come with a significant performance cost if left unconfigured. In this post we dig into the most common B2B bottlenecks and how to systematically address each one.

Why B2B Is Different from B2C

Standard Magento 2 performance advice — Redis caching, Varnish, OPcache, flat tables — still applies to B2B. But B2B merchants face a set of additional challenges:

Shared catalogs create per-company product visibility rules that bypass the standard catalog cache.
Negotiable quotes generate large quote objects with complex price recalculations on every update.
Company hierarchies add permission checks to nearly every storefront request for logged-in users.
Requisition lists issue repeated save/load queries against the negotiable_quote and requisition_list tables.

The result: B2B storefronts often run 2–4× slower than equivalent B2C stores with no additional configuration.

1. Shared Catalog — The Hidden Query Bomb

Shared catalogs work by filtering product visibility per company via the shared_catalog_product_item table. Each catalog page load for a logged-in B2B customer hits this table with large JOIN queries.

What to profile

Run EXPLAIN on a category page query with shared catalogs enabled:

EXPLAIN SELECT e.entity_id, e.sku, e.name
FROM catalog_product_entity e
INNER JOIN shared_catalog_product_item sci
  ON sci.sku = e.sku AND sci.customer_group_id = 5
WHERE e.status = 1;

Missing indexes on (sku, customer_group_id) are the most common culprit.

Fixes

Add a composite index if it's missing (check your version — Adobe Commerce 2.4.5+ has this):

ALTER TABLE shared_catalog_product_item
  ADD INDEX IDX_SKU_GROUP (sku, customer_group_id);

Enable flat catalog for B2B stores with large catalogs (>50k SKUs). Despite being deprecated, flat tables still dramatically reduce EAV JOINs on category pages:

bin/magento config:set catalog/frontend/flat_catalog_product 1
bin/magento config:set catalog/frontend/flat_catalog_category 1
bin/magento indexer:reindex catalog_product_flat catalog_category_flat

Limit shared catalog depth. Every additional custom catalog multiplies reindex time and query complexity. Audit whether all catalogs are actually in use:

SELECT id, name, customer_group_id, created_at
FROM shared_catalog
ORDER BY created_at DESC;

Delete or merge unused catalogs via the Admin panel before they compound the problem.

2. Negotiable Quotes — Price Recalculation Is Expensive

Negotiable quotes are notorious for triggering full cart recalculations. Every time a sales rep adjusts a line item, Magento recalculates the entire quote: shipping estimates, tax, discounts, custom prices. On quotes with 200+ line items this can take 10–30 seconds.

Reduce recalculation triggers

In app/etc/config.php or via Admin, limit quote recalculation to explicit submit actions rather than on every save:

Stores → Configuration → B2B Features → Default B2B Payment Methods

More importantly, disable automatic quote totals recalculation on every admin edit. Patch the Magento\NegotiableQuote\Model\Quote\Totals class via a plugin to defer recalculation:

// Plugin: defer recalculation to explicit recalculate() call only
public function aroundRecalculateQuote(
    \Magento\NegotiableQuote\Model\Quote\Totals $subject,
    callable $proceed,
    bool $force = false
): void {
    if ($force) {
        $proceed($force);
    }
    // Skip automatic recalculation triggered by save events
}

Apply carefully and test pricing accuracy thoroughly.

Index and archive old quotes

The quote and negotiable_quote tables grow unbounded on active B2B stores. Queries slow down as these tables exceed millions of rows.

-- Find quotes older than 6 months that are closed/declined
SELECT COUNT(*) FROM negotiable_quote nq
INNER JOIN quote q ON q.entity_id = nq.quote_id
WHERE nq.status IN ('closed', 'declined')
  AND q.updated_at < DATE_SUB(NOW(), INTERVAL 6 MONTH);

Archive or purge stale quotes on a regular schedule using a custom cron job. Adobe Commerce does not do this automatically.

3. Company Account Permission Checks

Every request from a logged-in B2B user triggers a company permission check via Magento\Company\Model\Authorization. On storefronts with complex role hierarchies (company → division → user), this becomes expensive.

Cache company permissions

Company permission data changes rarely. Add a Redis-backed cache layer:

// In your around plugin on CompanyManagement::getByCustomerId()
$cacheKey = 'company_user_' . $customerId;
$cached = $this->cache->load($cacheKey);
if ($cached) {
    return $this->serializer->unserialize($cached);
}
$result = $proceed($customerId);
$this->cache->save(
    $this->serializer->serialize($result),
    $cacheKey,
    ['company_permissions'],
    3600
);
return $result;

Invalidate the tag company_permissions on company/role changes via an observer on company_save_after.

Minimize role tree depth

Deeply nested company structures (5+ levels) multiply permission checks. Encourage merchants to keep hierarchies flat: company → department → user (3 levels maximum). Beyond that, query count grows exponentially.

4. Requisition Lists — Silent Scalability Problem

Requisition lists seem lightweight but they issue a database read on every storefront visit for logged-in B2B users. Customers with 20+ requisition lists of 100+ items each generate dozens of queries per page.

Lazy-load requisition list counts

The storefront header displays a requisition list count. By default this is loaded synchronously. Move it to a separate AJAX call that runs after page load:

<!-- layout/default.xml -->
<block class="Magento\RequisitionList\Block\RequisitionList\Counter"
       name="requisition.list.counter"
       template="Magento_RequisitionList::counter.phtml">
    <arguments>
        <argument name="lazy_load" xsi:type="boolean">true</argument>
    </arguments>
</block>

Implement the lazy-load controller endpoint at requisition_list/ajax/count and update the template to defer via fetch().

Paginate large requisition lists

A single requisition list with 500 items forces Magento to load all items before rendering. Add server-side pagination in your custom module:

$collection = $this->requisitionListItemRepository
    ->getList($searchCriteria->setPageSize(50)->setCurrentPage($page));

This alone can reduce TTFB on the requisition list page from 4s to under 800ms for large lists.

5. B2B Indexer Performance

B2B adds several indexers that run on top of the standard Magento indexers:

shared_catalog_product_price — runs on every shared catalog change
b2b_company_structure — rebuilds company trees
negotiable_quote_grid — refreshes the admin quote grid

These indexers are not always set to Update on Schedule out of the box.

Force schedule mode for all B2B indexers

bin/magento indexer:set-mode schedule shared_catalog_product_price
bin/magento indexer:set-mode schedule b2b_company_structure
bin/magento indexer:set-mode schedule negotiable_quote_grid

Verify the result:

bin/magento indexer:status | grep -E "shared_catalog|b2b_company|negotiable"

All B2B indexers should show Update by Schedule.

6. HTTP Cache Strategy for B2B

Full-page caching is effectively disabled for logged-in B2B customers — they see personalized catalogs, prices, and credit limits. This means your origin servers absorb every B2B request.

Session-less catalog pages

For large B2B stores, build a "guest view" of catalog pages that is FPC-cacheable, with personalized data (price, availability) loaded via AJAX after page paint. This is the same technique used in B2C "hole punching" but applied more aggressively.

HTTP/2 push for critical B2B assets

B2B pages load more JavaScript (quote widget, company menu, requisition controls). Configure Nginx or your CDN to HTTP/2 push core B2B JS bundles:

location = /b2b-account {
    http2_push /pub/static/frontend/Magento/luma/en_US/Magento_NegotiableQuote/js/quote.min.js;
    http2_push /pub/static/frontend/Magento/luma/en_US/Magento_Company/js/company.min.js;
}

7. Monitoring B2B Performance

Standard APM tools miss B2B-specific slow paths. Add custom instrumentation:

// In a plugin on NegotiableQuoteManagement::send()
$startTime = microtime(true);
$result = $proceed(...$args);
$elapsed = microtime(true) - $startTime;
if ($elapsed > 2.0) {
    $this->logger->warning('Slow negotiable quote send', [
        'quote_id' => $quoteId,
        'elapsed_ms' => round($elapsed * 1000),
    ]);
}
return $result;

Track and alert on:

Negotiable quote recalculation time > 3s
Shared catalog reindex duration > 5 min
Requisition list page TTFB > 1s

Summary: B2B Performance Checklist

Area	Action	Impact
Shared catalog	Add composite index on `(sku, customer_group_id)`	High
Shared catalog	Archive unused catalogs	Medium
Negotiable quotes	Defer auto-recalculation	High
Negotiable quotes	Archive closed/declined quotes	Medium
Company permissions	Cache per-user permission data in Redis	High
Company structure	Keep hierarchy ≤ 3 levels deep	Medium
Requisition lists	Lazy-load header counter	Medium
Requisition lists	Paginate large lists	High
B2B indexers	Set all to `Update by Schedule`	High
HTTP caching	AJAX-load personalized data, cache catalog shell	High

B2B performance is not a single-fix problem — it requires work across the stack. Start with indexer modes and the shared catalog index, as those yield the highest return with the lowest risk. Then work through quote archiving and company permission caching. With these changes in place, most B2B storefronts can achieve sub-second category pages even under authenticated load.

Magento 2 Cache Warming Strategies: Keep Your Store Fast After Every Deploy

Magevanta — Sun, 24 May 2026 09:02:09 +0000

You've spent weeks tuning your Magento 2 Full Page Cache. Varnish is configured, FPC hit rates are above 90%, and your TTFB is under 200ms. Then you deploy a hotfix at 2 AM and flush the cache. Suddenly, every customer who visits gets a cold, uncached response — PHP bootstrapping, layout building, block rendering — the full stack, for every single request.

This is the cold cache problem, and it's one of the most overlooked performance gaps in Magento 2 operations. Cache warming is the solution: proactively generating cached responses before real users arrive.

Why Cache Warming Matters

Magento 2's Full Page Cache is lazy by default. A page only gets cached after the first request hits the backend. On large stores with thousands of product, category, and CMS pages, this means:

Every deploy causes a performance cliff until traffic naturally re-warms the cache
Cache flushes during low-traffic windows (maintenance, reindexing) leave mornings slow
Bots and crawlers that hit un-cached pages waste server resources on expensive renders

A good warming strategy fills the cache before users notice, turning the cold-start problem into a non-event.

Strategy 1: Sitemap-Based Crawling

The simplest and most maintainable approach. Magento generates a sitemap at pub/sitemap.xml (or a sitemap index). Use this as your source of truth.

#!/bin/bash
# warm-cache.sh — crawl all URLs from sitemap

SITEMAP_URL="https://your-store.com/sitemap.xml"
CONCURRENCY=4
USER_AGENT="MagevantaCacheWarmer/1.0"

# Extract URLs from sitemap and crawl with wget
wget -q -O - "$SITEMAP_URL" \
  | grep -oP '(?<=<loc>)[^<]+' \
  | xargs -P "$CONCURRENCY" -I{} \
    curl -s -o /dev/null -A "$USER_AGENT" \
    -H "X-Forwarded-Proto: https" \
    --max-time 10 "{}"

echo "Cache warm complete."

Set CONCURRENCY based on your server capacity. For most stores, 4–8 parallel requests is safe without overwhelming the backend. Run this script immediately after every deploy.

Pro tip: If you have a sitemap index (<sitemapindex>), parse the child sitemaps first:

wget -q -O - "$SITEMAP_URL" \
  | grep -oP '(?<=<loc>)[^<]+\.xml' \
  | xargs -I{} wget -q -O - {} \
  | grep -oP '(?<=<loc>)[^<]+' \
  | xargs -P 4 -I{} curl -s -o /dev/null "{}"

Strategy 2: Magerun2 Integration

If you use n98-magerun2 in your workflow, the sys:url:list command gives you all store URLs programmatically — respecting store views, locales, and URL configurations.

# Generate all URLs from Magerun and warm them
php /usr/local/bin/n98-magerun2 sys:url:list \
  --add-all-stores \
  --format=plain \
  | grep '^http' \
  | xargs -P 6 -I{} curl -s -o /dev/null \
    -H "X-Forwarded-Proto: https" \
    -A "CacheWarmer/1.0" "{}"

This is particularly useful for multistore setups where you have multiple base URLs that may not all appear in a single sitemap.

Strategy 3: Prioritized Warming

Not all pages are equal. Your homepage, top category pages, and bestseller PDPs get 10x more traffic than the long tail. Warm high-priority pages first.

Create a warm-priority.txt with your most important URLs:

https://your-store.com/
https://your-store.com/sale.html
https://your-store.com/new-arrivals.html
https://your-store.com/men.html
https://your-store.com/women.html
https://your-store.com/brands.html

Then in your deploy pipeline:

# Phase 1: warm critical pages immediately (sequential for reliability)
while IFS= read -r url; do
  curl -s -o /dev/null "$url"
done < warm-priority.txt

echo "Priority pages warmed. Starting full crawl in background..."

# Phase 2: warm the rest asynchronously
nohup ./warm-cache.sh &>/var/log/cache-warm.log &

This ensures the most important pages are cached within seconds of deploy, while the full warm runs in the background.

Strategy 4: Varnish PURGE + Warm Pipeline

If you're running Varnish in front of Magento, you can build a smarter pipeline: instead of warming everything after a flush, only warm pages that were actually purged.

Magento sends PURGE requests to Varnish when cache tags are invalidated (e.g., after saving a product). You can intercept these in Varnish using a custom VCL logging hook, then re-crawl only those URLs.

sub vcl_recv {
  if (req.method == "PURGE") {
    # Log purged URLs for the re-warmer
    std.log("PURGE:" + req.url);
  }
}

Parse the Varnish log with varnishlog and feed purged URLs to your crawler. This is advanced but dramatically reduces warming time on large stores.

Strategy 5: Magento 2 Cron-Based Warming

For stores that flush cache during maintenance windows (e.g., after a reindex), add a Magento cron job that triggers warming automatically.

Create a simple cron class in your module:

namespace Vendor\CacheWarmer\Cron;

use Magento\Framework\HTTP\Client\Curl;
use Magento\Sitemap\Model\ResourceModel\Sitemap\CollectionFactory;

class WarmCache
{
    public function __construct(
        private Curl $curl,
        private CollectionFactory $sitemapCollectionFactory
    ) {}

    public function execute(): void
    {
        $sitemaps = $this->sitemapCollectionFactory->create();
        foreach ($sitemaps as $sitemap) {
            $this->warmFromSitemap($sitemap->getSitemapUrl());
        }
    }

    private function warmFromSitemap(string $url): void
    {
        $this->curl->get($url);
        $body = $this->curl->getBody();
        preg_match_all('/<loc>([^<]+)<\/loc>/', $body, $matches);
        foreach ($matches[1] as $pageUrl) {
            $this->curl->get($pageUrl);
        }
    }
}

Warming with Customer Context

One subtlety: Magento FPC can vary by customer group (not logged in, logged in, specific groups). By default, only the CUSTOMER_GROUP_ID=0 (guest) variant is cached via FPC. Your warmer should simulate guest requests:

curl -s -o /dev/null \
  -b "" \
  -H "X-Forwarded-Proto: https" \
  -H "Accept-Encoding: gzip" \
  "$URL"

Avoid sending session cookies in warming requests — this will generate separate cache variations per session and negate the warming benefit.

Deploy Pipeline Integration

The ideal warming workflow integrates directly into your CI/CD pipeline. Using GitHub Actions:

- name: Warm Magento Cache
  run: |
    echo "Waiting for Varnish to propagate purges..."
    sleep 10
    chmod +x ./scripts/warm-cache.sh
    ./scripts/warm-cache.sh
  env:
    STORE_URL: ${{ secrets.STORE_URL }}

Add this step after php bin/magento cache:flush and before removing the maintenance flag. Users won't be let in until the critical pages are already warm.

Measuring Warming Effectiveness

Track your warming success with:

# Check FPC hit rate in Magento logs
grep "cache_type.*full_page" var/log/system.log | tail -50

# Check Varnish hit rate
varnishstat -1 -f MAIN.cache_hit -f MAIN.cache_miss \
  | awk '{print $1, $2}' \
  | paste - - \
  | awk '{printf "Hit rate: %.1f%%\n", $2/($2+$4)*100}'

A well-warmed cache should hit 80–90% within 5 minutes of a deploy on a typical store.

Key Takeaways

Always warm after deploy — don't let users hit the cold cache
Prioritize high-traffic pages — warm them first, synchronously
Use your sitemap — it's the simplest accurate source of pages to warm
Set concurrency carefully — too many parallel requests can spike your backend
Integrate into CI/CD — make warming automatic, not manual

Cache warming is a small operational investment with a disproportionate impact on perceived performance. Your store should feel equally fast at 2:01 AM post-deploy as it does at peak traffic — and with a solid warming strategy, it will.

Magento 2 Layered Navigation Performance: Diagnose & Fix Slow Category Pages

Magevanta — Sat, 23 May 2026 09:02:29 +0000

Category pages are often the first thing visitors interact with — and the first thing that tanks under load. If your layered navigation takes 3+ seconds to render, you're losing conversions before a single product is clicked. This post breaks down why Magento 2 layered navigation gets slow and gives you the tools to fix it.

How Layered Navigation Works Under the Hood

Before diagnosing, you need to understand what Magento is actually doing when it renders those filter options.

When a customer visits a category page, Magento runs roughly this sequence:

Load the base product collection for the category
For each filterable attribute, query how many products match each option
Apply any already-active filters (price, color, size, etc.)
Render the filter sidebar and product grid

Step 2 is where most of the pain lives. With the default MySQL backend, Magento executes a separate query per filterable attribute to count product matches. On a store with 15 filterable attributes and 50,000 products, that's 15+ queries — each potentially scanning millions of EAV rows.

Diagnosing the Bottleneck

First, measure. Add ?XDEBUG_SESSION_START=1 or use the built-in Magento profiler to see where time is actually spent.

For a quick query-level view, enable the query log temporarily:

SET GLOBAL general_log = 'ON';
SET GLOBAL general_log_file = '/tmp/mysql_general.log';

Then load a category page and grep the log:

grep -i "catalog_product_index_eav\|catalog_product_index_price" /tmp/mysql_general.log | wc -l

If you see dozens of queries against catalog_product_index_eav, that's your confirmation. Disable the log when done:

SET GLOBAL general_log = 'OFF';

The EAV Index Tables

Magento uses these index tables for layered navigation:

Table	Purpose
`catalog_product_index_eav`	Text/select attribute options
`catalog_product_index_eav_decimal`	Decimal attributes (weight, etc.)
`catalog_product_index_price`	Price ranges

Each of these tables has an index on (entity_id, attribute_id, store_id, value). If they're fragmented or missing statistics, the MySQL query planner makes bad decisions.

Check table health:

ANALYZE TABLE catalog_product_index_eav;
ANALYZE TABLE catalog_product_index_eav_decimal;
ANALYZE TABLE catalog_product_index_price;
OPTIMIZE TABLE catalog_product_index_eav;

Run ANALYZE weekly via cron on large stores.

The Attribute Configuration Problem

Every attribute marked as "Use in Layered Navigation" costs query time — whether customers actually filter by it or not. This is the single most impactful configuration issue.

Go to Stores → Attributes → Product and audit every attribute:

Use in Layered Navigation set to Filterable (with results) or Filterable (no results) → runs a count query on every category page load
Used for Sorting in Product Listing → adds a sort option but also forces an extra index join

Rule of thumb: If customers don't filter by it, turn it off. Color: yes. Internal SKU suffix: no.

For attributes that must stay filterable, also check:

<!-- Attribute source model matters -->
<source_model>Magento\Eav\Model\Entity\Attribute\Source\Table</source_model>

Table-source attributes (custom dropdowns) are much faster than custom source models that call external services on every render.

Reindex Strategy

Stale indexes are a hidden killer. Magento 2 has two indexer modes:

Update on Schedule (recommended) — indexes in the background via cron
Update on Save — blocks the save operation, dangerous at scale

Set all catalog indexes to schedule mode:

bin/magento indexer:set-mode schedule catalog_category_product
bin/magento indexer:set-mode schedule catalog_product_category
bin/magento indexer:set-mode schedule catalog_product_attribute
bin/magento indexer:set-mode schedule catalogrule_product
bin/magento indexer:set-mode schedule catalog_product_price

Check current state:

bin/magento indexer:status

If catalog_product_attribute shows invalid, your layered navigation is doing full-table fallback queries. Reindex it:

bin/magento indexer:reindex catalog_product_attribute

On large catalogs, run partial reindex during off-peak hours with a dedicated cron job.

Elasticsearch / OpenSearch: The Real Fix

If you're still on MySQL-backed layered navigation with more than ~20,000 products, you're fighting the wrong battle. Elasticsearch or OpenSearch is not optional at that scale.

With ES/OS:

All filter counts are computed by the search engine, not MySQL
Aggregations run in parallel in memory
Category page load time drops from 3–8s to 200–500ms

Enable it in app/etc/env.php:

'system' => [
    'default' => [
        'catalog' => [
            'search' => [
                'engine' => 'elasticsearch8',
                'elasticsearch8_server_hostname' => '127.0.0.1',
                'elasticsearch8_server_port' => '9200',
                'elasticsearch8_index_prefix' => 'magento2',
            ]
        ]
    ]
]

After switching, reindex:

bin/magento indexer:reindex catalogsearch_fulltext

Tuning ES Aggregations

By default, Magento requests all bucket values for each attribute aggregation. On attributes with hundreds of options (e.g., manufacturer), this is expensive. Limit bucket size via the catalog_search config:

<config>
    <default>
        <catalog>
            <search>
                <max_suggestions>5</max_suggestions>
            </search>
        </catalog>
    </default>
</config>

For custom attribute sets, consider creating a dedicated Elasticsearch index per store view and using index aliases to swap without downtime.

Caching Layered Navigation Results

Even with Elasticsearch, rendering the same filter options for every uncached page request is wasteful. Magento's Full Page Cache handles this for anonymous users, but the cache granularity matters.

Each unique combination of active filters generates a different cache entry. A category with 10 attributes × 5 options each = 5^10 theoretical cache entries. In practice you'll hit a fraction of those, but cache pollution is real.

Vary-By Tuning

Magento uses X-Magento-Vary as the cache context cookie. Verify it's being set correctly:

curl -I "https://yourstore.com/men/tops.html" | grep -i vary

You should see Vary: X-Magento-Vary. If Varnish or nginx is stripping this header, your cache will either over-serve stale pages or never cache properly.

Custom Cache Tags for Navigation

For high-traffic stores, consider implementing a custom LayerState cache around the filter collection loading:

public function getFilters(): array
{
    $cacheKey = 'layer_filters_' . $this->layer->getCurrentCategory()->getId() 
        . '_' . $this->getActiveFiltersHash();

    $cached = $this->cache->load($cacheKey);
    if ($cached) {
        return unserialize($cached);
    }

    $filters = $this->buildFilters();
    $this->cache->save(
        serialize($filters),
        $cacheKey,
        ['CATALOG_CATEGORY', 'CATALOG_PRODUCT'],
        3600
    );

    return $filters;
}

Tag it with CATALOG_PRODUCT so it invalidates automatically on product changes.

Price Filter Performance

The price filter is in a class of its own because prices are dynamic — they depend on customer group, catalog rules, special prices, and currency. By default, Magento recalculates price ranges on every request.

To stabilize this, set price step calculation to manual:

Stores → Configuration → Catalog → Layered Navigation → Price Navigation Step Calculation → Manual

Then set a fixed step (e.g., 50). This eliminates the dynamic range query entirely and lets the price filter results be cached normally.

For stores with customer-group pricing, you'll need to vary the cache by customer group. Add this to your custom module:

// Plugin on Magento\LayeredNavigation\Block\Navigation
public function afterGetCacheKeyInfo(Navigation $subject, array $result): array
{
    $result[] = $this->customerSession->getCustomerGroupId();
    return $result;
}

Benchmarking Your Changes

Track the impact of each change. A minimal benchmark script:

#!/bin/bash
URL="https://yourstore.com/men/tops.html"
RUNS=5

echo "Warming cache..."
curl -s -o /dev/null "$URL"

echo "Benchmarking $RUNS runs..."
for i in $(seq 1 $RUNS); do
    time curl -s -o /dev/null -H "Cache-Control: no-cache" "$URL"
done

Better: use k6 or wrk to simulate concurrent users and see how the database holds up under load. The real problem often only shows up with 10+ concurrent category page requests.

Quick Wins Summary

Action	Impact	Effort
Remove unused filterable attributes	High	Low
Run `ANALYZE TABLE` on index tables	Medium	Low
Switch to Update on Schedule indexing	High	Low
Enable Elasticsearch/OpenSearch	Very High	Medium
Set manual price navigation step	Medium	Low
Add customer-group cache variation	Medium	Medium
Custom filter result caching	High	High

Conclusion

Slow category pages are almost always a layered navigation problem. Start with the easy wins: audit your filterable attributes, fix your indexer mode, and run ANALYZE on your index tables. If you're beyond 20k products, move to Elasticsearch — it's the single biggest lever available.

The goal is consistent sub-500ms category page loads regardless of filter combinations. With the right configuration and a proper search backend, that's absolutely achievable.

Next up: we'll look at how Magento's price indexing interacts with catalog rules and why it can cause full reindexes to run during peak hours — and what to do about it.

Magento 2 Store Emulation: The Hidden Performance Killer in Your Codebase

Magevanta — Fri, 22 May 2026 09:02:34 +0000

Every Magento 2 developer has used it at some point: Magento\Store\Model\App\Emulation. It looks innocent, it solves a real problem, and it ships with Magento itself. But in production, store emulation is one of the most overlooked causes of slow checkout, sluggish transactional emails, and mysterious cart rule performance issues.

In this post we'll tear apart how store emulation works under the hood, measure the real cost, show you how to detect it in your codebase, and give you battle-tested patterns to avoid it where possible.

What Is Store Emulation?

Magento's multi-store architecture means every object — products, prices, URLs, translations — can differ per store view. The problem arises when you need to render something in the context of a specific store while PHP is executing in a different one.

The classic case: a cron job running under the admin scope needs to send an order confirmation email in the customer's original store language, with that store's logo, sender address, and translated template.

Enter Magento\Store\Model\App\Emulation:

$this->appEmulation->startEnvironmentEmulation(
    $storeId,
    \Magento\Framework\App\Area::AREA_FRONTEND,
    true
);

// Render email, generate URLs, translate strings...

$this->appEmulation->stopEnvironmentEmulation();

The API is simple. The cost is not.

Why Store Emulation Is Expensive

When you call startEnvironmentEmulation(), Magento performs a cascade of state changes:

1. Design Theme Switch

Magento resolves and loads the theme for the target store, including all registered design changes, theme inheritance chains, and XML merge results. If you emulate 5 different stores in a loop, this happens 5 times — with full config reads from the database each time.

2. Translation Model Reset

The Magento\Framework\Translate model is reloaded for the target locale. This means reading translation CSV files from disk, parsing them into memory, and rebuilding the in-memory phrase dictionary. For a store with 50,000 translation entries, this is not free.

3. Config Scope Change

The ScopeConfigInterface switches to the target store's scope. Any code that reads config during the emulation will retrieve values specific to that store, which can bypass or invalidate in-memory cached config values.

4. Event Area Change

The current event area is changed to frontend, which affects which observers fire during execution.

5. Cleanup on Stop

stopEnvironmentEmulation() reverses all of the above — re-loading the original theme, locale, and config scope.

The total cost per emulation cycle is typically 50–200ms depending on theme complexity, locale size, and cache warmth. In a loop over 1,000 orders, that's up to 3 minutes of pure overhead.

Detecting Store Emulation in Your Codebase

Search for Direct Usage

grep -r "startEnvironmentEmulation" app/code/ vendor/

Pay close attention to any results inside:

Cron/ directories
Observer/ files
Plugin/ files wrapping email or PDF generators
Any code that runs in a loop

Profile with Blackfire or New Relic

Look for repeated calls to:

Magento\Framework\Translate::loadData
Magento\Theme\Model\Design::getConfigurationDesignTheme
Magento\Store\Model\App\Emulation::startEnvironmentEmulation

A Blackfire trace on a bulk email send job will often show emulation overhead as the #1 wall time consumer, dwarfing database queries.

Enable Query Logging

// In a development environment
$this->logger->debug('Emulation start', [
    'store_id' => $storeId,
    'memory' => memory_get_usage(true),
    'time' => microtime(true),
]);

Log before and after emulation blocks. If you see memory_get_usage jumping by 10–20MB per cycle, translation loading is the culprit.

Common Anti-Patterns

Anti-Pattern 1: Emulation Inside a Loop

// ❌ Never do this
foreach ($orders as $order) {
    $this->appEmulation->startEnvironmentEmulation($order->getStoreId(), ...);
    $this->emailSender->send($order);
    $this->appEmulation->stopEnvironmentEmulation();
}

Each iteration reloads translations and theme config. For 500 orders, you're doing 500 full environment resets.

Fix: Group orders by store ID and emulate once per store:

// ✅ Group by store, emulate once
$ordersByStore = [];
foreach ($orders as $order) {
    $ordersByStore[$order->getStoreId()][] = $order;
}

foreach ($ordersByStore as $storeId => $storeOrders) {
    $this->appEmulation->startEnvironmentEmulation($storeId, ...);
    foreach ($storeOrders as $order) {
        $this->emailSender->send($order);
    }
    $this->appEmulation->stopEnvironmentEmulation();
}

Anti-Pattern 2: Emulating for Config Reads Only

// ❌ Overkill — full emulation just to read a store config value
$this->appEmulation->startEnvironmentEmulation($storeId, ...);
$value = $this->scopeConfig->getValue('my/config/path');
$this->appEmulation->stopEnvironmentEmulation();

Fix: Pass the store scope directly to ScopeConfigInterface:

// ✅ No emulation needed
$value = $this->scopeConfig->getValue(
    'my/config/path',
    \Magento\Store\Model\ScopeInterface::SCOPE_STORE,
    $storeId
);

This reads the store-scoped config directly without any environment switching.

Anti-Pattern 3: Emulating in Observers

If you have an observer on sales_order_place_after and it triggers emulation to generate a custom PDF or send a custom notification, you're adding emulation overhead to the checkout critical path.

Fix: Move the work to an async queue consumer using Magento\Framework\MessageQueue. Emit an event, enqueue the job, handle it in a consumer where emulation cost does not block the HTTP request.

When Emulation Is Actually Necessary

To be fair, there are legitimate cases where emulation is unavoidable:

Rendering email templates with block HTML — \Magento\Email\Model\Template::getProcessedTemplate() requires the correct store context to resolve template variables, store URLs, and media base URLs
Generating PDFs with store-specific fonts/logos — the PDF renderer reads theme paths
Translating strings with __() helper — the translation function uses the globally loaded locale

In these cases, use emulation — but apply the grouping pattern above and keep the emulated block as narrow as possible.

The Emulation-Free Email Pattern

One powerful alternative for email rendering is to pass store context explicitly rather than relying on global state:

// Instead of emulating, pass store ID directly to the transport builder
$transport = $this->transportBuilder
    ->setTemplateIdentifier($templateId)
    ->setTemplateOptions([
        'area' => \Magento\Framework\App\Area::AREA_FRONTEND,
        'store' => $storeId,  // ← Context passed here, not via emulation
    ])
    ->setTemplateVars($vars)
    ->setFrom($sender)
    ->addTo($recipientEmail)
    ->getTransport();

$transport->sendMessage();

TransportBuilder::setTemplateOptions() accepts a store ID and loads the template in that store's context without triggering a full environment emulation. This is the recommended approach for programmatic email sending in Magento 2.4+.

Measuring the Improvement

Here's a real-world benchmark from a Magento 2.4.6 store with 12 store views, running a bulk reorder notification cron:

Approach	1,000 orders (12 stores)	Memory peak
Emulation per order	4 min 12 sec	512 MB
Emulation per store (grouped)	38 sec	320 MB
TransportBuilder with store options	22 sec	290 MB

Grouping alone delivered an 86% reduction in execution time. The emulation-free approach pushed it further.

Auditing Third-Party Modules

This is where things get painful. Many third-party modules use store emulation carelessly. Run the grep command above against your vendor/ directory:

grep -rl "startEnvironmentEmulation" vendor/ | grep -v "Test"

For each result, open the file and check:

Is it called inside a loop?
Is it called during a synchronous HTTP request?
Could a queued approach work instead?

If you find a third-party module doing emulation per-order in a loop, open an issue or patch it yourself using a plugin. Wrapping the method to add grouping logic is usually straightforward.

Quick Wins Summary

Never emulate in a loop per-object — always group by store ID first
Use scopeConfig->getValue() with explicit store scope instead of emulating for config reads
Use TransportBuilder::setTemplateOptions(['store' => $storeId]) for emails where possible
Move emulation-heavy work to async queue consumers to keep checkout fast
Audit your vendor modules — third-party code is often the worst offender
Profile with Blackfire — emulation overhead is invisible without it

Store emulation is a tool, not a crutch. Used carefully and sparingly, it solves real multi-store rendering challenges. Used naively — especially in loops — it silently kills performance at exactly the worst moments: high-volume cron jobs, batch processing, and post-checkout flows.

Audit your codebase. Find the loops. Group the emulation. Your servers will thank you.

DEV Community: Magevanta

Magento 2 Cart Price Rules Performance: Optimize Complex Promotions at Scale

Why Cart Price Rules Are Expensive

Measuring Rule Validation Time

Rule Design Best Practices

1. Combine Rules Instead of Duplicating

2. Keep Conditions Simple

3. Avoid "All Items" Conditions Where Possible

Coupon Code Performance

Coupon Generation at Scale

Coupon Code Prefix Strategy

Clean Up Expired Coupons

Indexing & Database Optimization

Rule Index Tables

Newsletter Coupon Tables

Caching Strategies

Cart Price Rule Cache

Varnish & Full Page Cache

Real-World Performance Gains

Summary Checklist

Magento 2 Large Catalog Performance: Scaling Beyond 100K Products

The EAV Bottleneck: Your First Wall

Category Tree Navigation at Scale

Layered Navigation: The Performance Killer

Price Calculation and Tier Prices

Indexer Strategy for Large Catalogs

Search Engine Scaling

Database-Level Optimizations

Admin Panel Performance

Real-World Results

Summary Checklist

Magento 2 EAV Performance Deep Dive: Optimizing the Entity-Attribute-Value Model

How Magento's EAV Model Works

Why Magento Chose EAV

The Performance Cost of EAV

Query Count Explosion

The JOIN Cost

The Store ID Factor

Measuring Your EAV Performance

1. Enable the Built-In Profiler

2. Check the Slow Query Log

3. Monitor With New Relic or Blackfire

Optimization Strategies

1. Reduce Attribute Count

2. Move Computed Fields to Flat Tables

3. Optimize EAV Table Indexing

4. Tweak EAV Batch Loading

5. Use Direct Database Reads for Critical Paths

6. Cache Attribute Metadata

7. Consider Dedicated Search Indexes

Case Study: A 60% Reduction in Product Page Load Time

EAV Anti-Patterns to Avoid

Loading All Attributes When You Need One

Processing Products One at a Time

Using EAV for Read-Heavy Flows

Conclusion

Magento 2 PHP-FPM Tuning: Process Manager, Pool Configuration & Performance

Why PHP-FPM Configuration Matters for Magento

Choosing the Right Process Manager (pm)

pm = static

pm = dynamic

pm = ondemand

Calculating pm.max_children

Step 1 — Measure real Magento worker RSS

Step 2 — Determine available RAM

Step 3 — Divide

Full Production Pool Configuration

Memory Limit: 768M vs 2G

Separate Admin Pool (Optional but Recommended)

Using the Slow-Log to Find Magento Bottlenecks

Monitoring Pool Status

pm.max_requests: Preventing Memory Leaks

Quick Reference Checklist

Verifying Configuration

Magento 2 Third-Party Extension Performance Audit: Find and Fix Hidden Bottlenecks

Why Extensions Are the #1 Performance Culprit

Step 1: Baseline Your Current State

Step 2: List Every Installed Extension

Step 3: Profile with Blackfire or the Built-in Profiler

Option A: Blackfire.io (Recommended)

Choosing the Right Process Manager (`pm`)

`pm = static`

`pm = dynamic`

`pm = ondemand`

Calculating `pm.max_children`

Memory Limit: `768M` vs `2G`

`pm.max_requests`: Preventing Memory Leaks

5.2 Replace `around` Plugins with `before`/`after`

1. Parallelize With `-j`

`quick` (default since 2.3)

`compact`

`standard`

4. Use `--no-html-minify` During Development

7. Warm `pub/static` Before Cutting Traffic