The Catalog UI trade-off: performance or better UI

I supposed this is a well known feature, but I was asked more than once about it, so it’s better to write something here to clarify the confusions.

If you have some very, very big catalogs, you probably have seen this “notification” in Catalog UI

By default, the Catalog UI groups a product and its variations in a parent-children view (they are not exactly parent-children, by the way). However, to do that, it needs to know about all the entries in that specific category. If it’s a small category, it should be no problem, but if it’s big one, then it’s inevitable slow. The lazy loading which the catalog content list only loads the contents when you scroll to them is not helping in this matter. Moreover, the grouping introduces an overhead for the UI, and having too many groups can severely affect the performance. Trust me, you won’t like a sluggish UI.

This improvement was introduced way back – 7.11 if I remember correctly – thanks to my colleague Magnus Rahl. To this day it’s still valuable – the performance was improved – but not that much to remove the threshold completely (And the improvement to the catalog versioning in Commerce 9 should have nothing to do with this).

When you see this notification, and if you’re unhappy with it, you have two (primary) options: Either to sub-categorize your category – i.e. introduce sub categories so each will have a smaller number of entries. Or increase the value of threshold.

Each approach has its own disadvantages. Sub-categorizing might break your SEO, while the second approach will undoubtedly effect the UI performance. Your call!

Now – the tricky part – which number to configure in SimplifiedCatalogListingThreshold setting. Obviously, it must be greater than the biggest number of entries in a category. But how to obtain that number? I’ve seen the confusion to raise that value to 3000, 5000, or even 10000 and it’s still not working. No, you can’t guess, you have to know for sure.

One simple option is to look at Commerce Manager Catalog Management. There is a small text in right corner of the list which shows the number of entries in that category (No, it’s not available in the Catalog UI, but I assume it would be helpful?)

 

The nuke option is to look at the database. Usually we recommend to avoid manipulate the database directly, as it can be dangerous – but here is a little code which only queries data (so practical harmless)

SELECT CatalogNodeId, Count(CatalogEntryId) 

FROM dbo.NodeEntryRelation

GROUP BY CatalogNodeId

ORDER BY Count(CatalogEntryId) DESC

Now you know the biggest number of the entries in a category – just change the threshold in setting. Try it and see if the UI Performance is acceptable to you.

Configure Apache with Load-balancer / Proxy

If your Apache website is under a load-balancer or proxy, some features might not work very well. The proxy, for example, might “hide” the true IP from clients, the address your application sees in REMOTE_ADDR attribute (PHP, for example) will be the IP of the proxy renders IP-ban in .htaccess useless.

If such things happen, time to do some configuration. First, you need to enable the mod_remoteip module to handle requests through a proxy. It will allow you to “rewrite” some headers in the request to make your web application to know the true client IP.

Continue reading “Configure Apache with Load-balancer / Proxy”

Upgrading to TeamCity 9.x: the JRE headaches

Today I updated our TeamCity server from 8.15 to 9.17. We need to support C# 6.0 so it’s an essential move. TeamCity 10 is still EAP and we would wait a couple of months after it comes out to make sure all the plugins are supported.

The installation was a breeze – the installer detected there was a previous version and offered to uninstall it. All good. Until there was a browser window opened so I can continue the configuration, but http://localhost/ only returned time out.

When I opened the Service Management (services.msc), it looked like the service was not running. I tried to start it, but then it stopped immediately. Events viewer was not exactly helpful, it gave a very obscure information:

The description for Event ID 404 from source TeamCity (see below) cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

===============================================================
TeamCity JetBrains JetService v1.1.755.777
c:\TeamCity\bin\TeamCityService.exe
Service process exited without service stop request
===============================================================
Continue reading “Upgrading to TeamCity 9.x: the JRE headaches”