Magento 2's Hidden Performance Drain: Uncached Store Scopes and Database Overload

Magento 2's Hidden Performance Drain: Uncached Store Scopes and Database Overload

As e-commerce migration experts at Shopping Mover, we constantly monitor the Magento ecosystem for insights that can impact store performance and stability. A recent GitHub issue (#41730) has brought to light a significant, yet subtle, performance bottleneck in Magento 2 that has persisted since version 2.2.0. This issue reveals that critical store configuration data—specifically for store views, websites, and store groups—is being queried directly from the database on every single storefront request, even when the Full Page Cache (FPC) is active.

The Core Problem: Persistent Database Queries for Store Scopes

The issue, reported by lbajsarowicz, details how Magento 2 instances, regardless of cache status, execute three full-table SELECT queries on the store, store_website, and store_group tables for every request. This happens because the 'scopes' configuration type, unlike the 'system' configuration, is not properly cached. Even a built-in FPC hit, which should ideally serve content entirely from cache, still incurs these three database calls.

The author meticulously demonstrated this with a clean Magento 2.4-develop instance, showing that a typical FPC bypass request (e.g., customer login) results in 10 queries, with one each for store, website, and store group. More strikingly, a built-in FPC HIT still generates 4 queries, with these three tables accounting for the majority:

SELECT `store_website`.* FROM `store_website`
SELECT `store_group`.* FROM `store_group`
SELECT `store`.* FROM `store`

On an FPC hit, these three queries, along with a SELECT @@version, constitute all four database interactions, highlighting their disproportionate impact.

Unpacking the Technical Details

The root cause lies within Magento's configuration loading mechanism. The Magento\Store\App\Config\Type\Scopes::get() method, responsible for retrieving scope data, bypasses any caching attempt. Instead, it unconditionally calls its source, Magento\Store\App\Config\Source\RuntimeConfigSource. This RuntimeConfigSource then proceeds to execute the aforementioned SELECT * queries directly against the database whenever it's available.

Intriguingly, this behavior is a regression. During the development of Magento 2.2, the Scopes config type initially included a cache frontend, serializer, and cache tags. However, a specific commit (26339335ee5, related to MAGETWO-56989) removed these caching mechanisms before the 2.2.0 release, leaving only in-memory memoization which resets with each request. This stands in contrast to the system config type, which correctly utilizes the config cache.

Furthermore, developers often use bin/magento app:config:dump scopes to optimize configuration loading. However, the issue confirms that this command does not mitigate the problem, as the runtime database source is still queried on every request.

Impact on Magento Stores and Performance

The implications for Magento 2 merchants and developers are significant. Each of these three queries involves a database round trip, fetching, and hydrating every row from the respective tables. This cost scales directly with the number of store views, websites, and store groups configured in an instance. For complex multi-store setups, this translates to a substantial, unnecessary performance overhead on every single uncached storefront, GraphQL, and REST API request, and critically, on every built-in FPC hit.

The process is triggered early in the request lifecycle by StoreManager::getStore() through StoreResolver, even before the built-in FPC is checked. This explains why FPC hits still suffer the performance penalty.

Community Engagement and Resolution

The good news is that the issue author, lbajsarowicz, has indicated they are actively working on a solution, as noted by their comment: @magento I am working on this. This suggests a fix is in progress, which will likely involve re-implementing proper caching for the scopes configuration type, allowing this vital data to be served from cache when warm.

This incident underscores the importance of diligent performance monitoring and community contributions to refine the Magento platform. While we await the official fix, this insight serves as a crucial reminder for developers to scrutinize database query logs, even on seemingly optimized pages, to uncover hidden performance drains.