How Amasty’s Approach to Performance Testing and Optimization Helped to Speed Up a Module by 72%

Amasty’s Store Locator extension is a tool designed to effectively bridge the gap between the online and offline shopping experiences. We’ve developed the extension for e-commerce businesses with physical retail locations to help them offer in-store pickup, increase foot traffic, and foster stronger relationships with clients.

With a score of 4.8/5, our extension has reportedly helped clients to achieve “more visitors” and “increased sales in physical stores”. But the success of Store Locator isn’t something that Amasty’s team achieved overnight. 

Here’s how our approach to performance testing and Magento optimization helped us get the most out of the module and meet the needs of even large-scale businesses. 

Catering to Enterprise-Level Requirements

Once Store Locator was first rolled out, it became highly popular with many clients. Amasty’s partners and customers were positively impressed with the module, finding it “conveniently scalable” and “easy to fill with import data”. 

The extension soon caught the attention of big corporations, and our requirements for the module’s performance matured. While Store Locator previously served businesses with less than 200 stores and could quickly load all locations onto the screen, it now had to handle over 2,000 physical retail locations – and display them just as fast. 

With proper monitoring in place, our team knew that they could ensure the extension’s flawless performance.

Performance Testing with Blackfire

To run realistic profiling and monitoring of all modules, Amasty’s team leverages Blackfire.io. For Store Locator v.2.5.7, we replicated enterprise-like conditions by creating a new virtual environment with 2,100 instead of 200 store locations. Among the metrics we observed were: 

• Wall-clock time (or simply Wall Time) – Overall time needed to perform a code function. It includes:
• CPU time – The time a CPU needs to compute the scripts.
•  I/O time – Time when the code can't run (for instance, because of a request to the database).
• Peak memory – Memory resources used in performing a function.
• The Biggest Wall Time – the highest result of Wall Time, with:
• inclusive time, where the time includes time in the function and all its children functions; 
• exclusive time, or the time spent in the function itself, excluding children.
• Compare Wall Time (and Percentage) – the difference between Wall Time results of the two latest releases, in seconds and percentage.
• Compare the Biggest Wall Time (and Percentage) – the difference between the Biggest Wall Time results of the two latest releases, in seconds and percentage.

Planning and Introducing Optimizations

When planning the release of Store Locator’s v. 2.5.7 testing, we noticed the slowdowns on three key pages: 

• amlocator (the module’s main view)
• Locate nearby
• Filter by attribute 

Our team aimed to improve the performance of these pages by introducing partial caching and optimizing several code functions. The results of this optimization yielded an average of a 29% speed improvement and were released as Store Locator v. 2.6.0. This was a step forward, but we continued working to achieve even faster performance in v. 2.6.2. 

In Store Locator v. 3.0.0, Amasty decided to introduce major changes. First, we expanded the testing environment to feature 3,000 virtual location entities and added four specific data attributes (including business hours) to each. Next, to create a testing dataset that was as realistic as possible, we attached review data to some of the locations.

Finally, striving to get the best results of the optimization, our team chose to rework the Location Model by: 

• Moving the following methods out of the Location Model: getProductConditions, getStoreIds, getWebsiteIds, getConditionsInstance, getActionsInstance, getMarkerMediaUrl, getLocationReviews, getLocationAverageRating, getDateFormat, getLocationDescription, getActions, setModelFlags.
• Optimizing sub-entities and attribute data.  
• Removing setTemplatesHtml.
• Reworking condition functions.
• Refactoring  __construct methods.

Results of Continuous Performance Optimization 

All the strategic and continuous optimization measures have significantly enhanced the performance of the Store Locator module and have resulted in a 72% acceleration of its performance thus far.