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%.

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