fbpx
Cracking the Code: Unraveling the Unexpected Performance Pitfall in Magento 2.3's Search Term Cache

Cracking the Code: Unraveling the Unexpected Performance Pitfall in Magento 2.3’s Search Term Cache

"Cracking the Code: Unraveling the Unexpected Performance Pitfall in Magento 2.3's Search Term Cache"

The introduction of the popular search term cache feature in Magento 2.3 has inadvertently led to an unforeseen performance issue, causing a significant strain on databases and creating a noticeable slowdown in website functionality. This problem, which persists even in the latest versions and when using ElasticSearch, has been traced back to a specific query that takes an extensive amount of time to execute. This blog delves into understanding this unexpected pitfall, exploring its causes, implications, and possible solutions in the quest to optimize the performance of websites running Magento 2.3 and beyond.

Unraveling the Performance Issue in Magento 2.3's Search Term Cache

The root of the performance issue lies in an unlikely place: the addition of the popular search term cache feature in Magento 2.3.0. Although intended to enhance the system's efficiency, it has instead turned into a thorny issue, causing a notable increase in the database CPU load. While the likely suspect would be that the problem arises from scaling to accommodate a live site with millions of search terms, the reality is more nuanced.

Instead of scaling, the performance issue is tied to a specific query, posing significant strain on the database and culminating in slow queries. This query, SELECT DISTINCT COUNT(*) FROM search_query AS main_table WHERE (main_table.store_id = 1) AND (num_results > 0), is the proverbial wrench in the works. In a table as voluminous as the search_query table, the execution of this query is notably time-consuming, thereby impacting the search functionality of the website.

Drilling Down the Problematic Query: The Core of the Issue

The problematic query is a distinct count on the 'search_query' table where 'store_id' is 1, and 'num_results' is greater than 0. What exacerbates the issue is size: the larger the 'search_query' table, the longer the query takes to complete. This is a bottleneck to system performance, particularly on live sites that accumulate millions of search terms.

While it might be easy to lay the blame on the complexity of the table or the number of search terms, the real offender is the 'num_results > 0' condition. This condition within the query takes up a significant amount of time when executing, thereby slowing down the overall system. Removing the 'num_results' condition from the troublesome query might seemingly improve its performance. However, the implication of its removal on the search functionality is unclear and warrants further investigation.

Dissecting the Role of the DISTINCT Operator and num_results Condition in Query Performance

Analyzing the query further, we find two critical components in question: the DISTINCT operator and the num_results condition. The DISTINCT operator is a potent tool when dealing with duplicate data. However, its use within this query is redundant and detrimental to performance. This redundancy stems from the fact that the 'search_query' table already has a unique constraint on 'query_text' and 'store_id', making the DISTINCT operator unnecessary.

Moreover, removing the DISTINCT operator from the query significantly improves its performance, without affecting the results. However, the full impact of this alteration on overall system functionality is yet to be comprehensively evaluated.

The num_results condition, on the other hand, is a different beast. While the removal of this condition improves the query performance, its impact on search functionality is not clear enough to warrant a definitive solution. In a system as complex as Magento, any change, no matter how small, can have far-reaching consequences. Therefore, a more thorough examination is required before implementing any alterations.

In conclusion, the performance issue plaguing Magento 2.3's Search Term Cache is a complex interplay of an ill-optimized query, redundant DISTINCT operator, and a nebulous 'num_results' condition. By unraveling these elements, we are a step closer to devising a viable solution that can restore system performance without compromising on functionality.

The High Cardinality Problem: Impact and Potential Solutions

A closer examination of the performance issue reveals that it results from the high cardinality of the search terms and the costly insertions into the search_query table. The term 'cardinality' refers to the uniqueness of data in a specific column of a database. High cardinality signifies a large proportion of unique, non-repeated terms. In the case of Magento 2.3, this high cardinality is found in the search_query table, leading to millions of records, each requiring processing.

The cost of these frequent inserts into the table, combined with the use of SELECT DISTINCT in the query, drastically slows the system's performance. This DISTINCT operator, which eliminates duplicate entries in the result set, is unnecessary in this context because the search_query table already possesses a unique constraint on query_text and store_id, making it redundant.

Eliminating the DISTINCT operator from queries within the Magento\Search\Model\ResourceModel\Query\Collection file could significantly improve performance, as it would relieve the system from the arduous task of processing millions of records while also maintaining the integrity of the results.

Another potential solution involves managing the high cardinality problem. Asynchronous insertion of search terms in batches or even limiting the number of search terms tracked could reduce the strain on the database. However, it's crucial to strike a balance between performance optimization and maintaining the search functionality's usefulness and effectiveness.

Looking Ahead: Ongoing Challenges and Paths to Performance Optimization

Despite the potential solutions, the performance issue remains a significant challenge, affecting websites running even the latest versions of Magento, such as 2.4.5-p4. Even if the problematic DISTINCT operator is removed, and high cardinality managed, the issue is not completely resolved. A comprehensive solution that is scalable and doesn't compromise the search functionality's effectiveness is still in process.

The use of ElasticSearch as a search engine does not resolve the performance issue either, as the main search bar in Magento continues to hit the MySQL search_query table, causing performance issues. This problem also persists in the admin panel, slowing down backend operations and potentially affecting overall website management.

Magento has confirmed the issue and committed to addressing it in the development process. While there is currently no specific fix, patch, or PR mentioned, the discussion around this problem has led to potential workarounds and the identification of the root cause of the issue. This understanding is a crucial first step toward developing an effective, long-term solution that optimizes performance without compromising on functionality.

As Magento continues to work on this issue, it is critical for database administrators and website managers to stay up-to-date on the latest developments. By understanding the issue and its potential solutions, they can take proactive steps to mitigate its impact and optimize their website's performance. From removing redundant operators in the database to managing high cardinality search terms, these measures can help maintain a smooth, efficient search functionality for a seamless user experience.

Indeed, this Magento performance pitfall provides an important reminder: continually monitoring system performance, staying abreast of updates, and understanding the underlying database operations are key to maintaining a robust, fast, and efficient web platform.

Accordingly, solving the performance pitfall in Magento 2.3's Search Term Cache requires a multi-faceted approach that not only scrutinizes the root issue but also understands the implications of potential solutions.

• First, the elimination of the redundant DISTINCT operator can significantly enhance the query performance. This minor modification can yield substantial improvements, relieving the system from the arduous task of processing millions of unique search terms.

• Second, managing the high cardinality of search terms through asynchronous insertions or limiting the number of tracked terms could further streamline system performance. However, it's crucial to tread carefully in this arena to prevent any negative impact on the search functionality's effectiveness.

• Third, staying abreast of Magento's updates regarding this performance issue is vital. As Magento is actively working on this issue, anticipating future fixes and updates can prepare database administrators and website managers to act swiftly, ensuring optimal system performance.

By way of summary, the performance issue in Magento 2.3's Search Term Cache is a complex beast that demands rigorous analysis, nuanced understanding, and a proactive response. While we are a step closer to resolving this issue, the path ahead involves continued investigation, potential system alterations, and a keen watch on Magento's ongoing development process. With these measures, we can work towards a robust, efficient, and smooth-running Magento platform that delivers a seamless user experience.

YouTube
LinkedIn
LinkedIn
Share