de_DEus

IntegerNet_Solr Speeds Up Category Pages – New Features in Version 1.3

In the beginning of November, we have released version 1.3. of our Solr Search Module “IntegerNet_Solr”, integrating the option to display Magento category pages based on Solr’s data. Why and in which cases this makes sense, that is what we will explain here. We have also conducted a small performance test, so stay tuned.

“What’s wrong with Magento’s own way of displaying categories?”

In general, there’s nothing wrong with it. However, under certain conditions categories can become a real bottle neck for your site’s performance, outbraking your whole system:

  • many products (at least with an upper five-figure portfolio)
  • generic categories with many products
  • intensive use of layered navigation

Especially if several of these points apply, Magento reaches its limits.

“But I have got Varnish that caches all category pages”

Varnish, other reverse proxies or full page caches are appropriate measures for performance optimisation. Still, they can only cache a limited number of pages for a limited period of time. Usually, category pages are included in these caches. As soon as one or more filters have been selected, the filtered results are no longer cached because the number of possible filter combinations (and thus, page URLs) is extremely high. It is almost impossible to cache all possible variations if your Magento store contains a greater number of products, categories and/or filters. Therefore, even if in general a caching system is used, some category pages will always be provided by Magento. As a result, a standard setup can quickly result in loading times of several seconds. In combination with many visitors it might even fully occupy your server.

Performance Tests

In our example, we have tested the following setup:

  • Magento Community Edition 1.9
  • rwd/default theme
  • 100.000 simple products in one category
  • 10 filter attributes with 10 options each, evenly distributed among all products
  • 4 filter have been randomly selected, so the filtered results contained approx. 10 products
  • test series of 100 category page views, each with newly selected filters or new search terms (no repetitions)
  • “Flat Catalog” activated
  • all caches activated
  • “Display Product Count” deactivated
  • Local server without any additional system load

We have imported the products in Magento using a simple AvS_FastSimpleImport script (download the import script). Before running the import, we had to create the appropriate attributes (“attribute 1..10”) together with the correct options (“Option 1..10”). Afterwards we generated the category url with four set filters and automatically loaded the page. During the page load, the time was measured and automatically saved. We have measured the following values for a standard Magento installation and for Magento with our IntegerNet_Solr extension:

Category display with four random activated filters

Average Minimum Maximum
Magento standard 15,13s 13,61s 21,19s
IntegerNet_Solr 0,68s 0,59s 0,80s

While we were at it, we seized the opportunity and did the same test for search results pages – with and without filters. The results:

Search results page with four random activated filters

Average Minimum Maximum
Magento standard 17,16s 15,63s 17,13s
IntegerNet_Solr 0,77s 0,58s 0,89s

Search results page without activated filters

Average Minimum Maximum
Magento-Standard 1,81s 0,77s 2,79s
IntegerNet_Solr 0,70s 0,61s 0,83s

Conclusion

As the performance tests show, under certain conditions page loading times quickly escalate when only the standard Magento features are in use. To solve this problem, we have integrated displaying category pages in our Solr module. The measured differences of page loading time are striking. Compared to Magento, using Solr reduced page loading time by up to 95%.

Comparison of Page Load Times in Magento Standard and IntegerNet_Solr

This example is certainly extreme in some aspects, however, not unrealistic. If you soften some of the values, a strong difference in performance is still clearly visible. Cutting loading time to half or a third of its original size is already a great improvement. Since a single additional second of loading time can cause a loss in conversion rate by 7%, as a recent study of Germany’s Top 100 online stores shows, investing in performance optimisation pays off after a very short time.

Learn more about IntegerNet_Solr

Andreas von Studnitz

Author: Andreas von Studnitz

Andreas von Studnitz is a Magento developer and CEO of integer_net. His main areas of interest are interface development, backend development, Magento consulting and giving developer trainings. He is a Magento Certified Developer since 2011 and a Magento Certified Solution Specialist since 2014.

More Information · Twitter · GitHub

This Post has 1 Comment

Leave a comment