And finally the much anticipated 4.5 firmware of PlayStation 4/4 Pro has arrived, with some very neat features: extended storage, custom themes. It’s a big improvement for PS4 users, well, almost: the firmware comes with a big problem for ones who are using wifi: the download speed is now terrible, and even worse, the lag in game is making the games unplayable. Before 4.5, I had no problem joining matches on Uncharted 4, and playing Titanfall was very smooth – ping is never more than 100ms. After 4.5, I can’t hardly join a match on Uncharted 4 (errors in connections), and the lag in Titanfall spikes to more than 2000ms, making the game totally unplayable. Test Internet Connection shows that I have a a few hundred Kbps upload and download, when the wifi connection is supposed to be 130Mbps (PS4 ony has 2.4Ghz wifi 802.11 b/g/n, only PS4 Pro has 5Ghz wifi), and my internet connection is 250/100Mbps, so that must be a big problem somewhere.
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)
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.
This is the second part of http://vimvq1987.com/2016/11/debug-net-memory-dump-windbg-crash-course-part-1/, – which is far from complete. In this post, we will explore the Large Object Heap (LOH) of a .NET application with WinDBG
Why LOH? It’s a special heap contains the memory objects which are more than 85000 bytes in size – which, previously, never compacted (that was changed with .NET 4.5 when you have an option to compact LOH, but beware of the consequences).
If you know about the generation garbage collection in CLR, you already know that when an object is no longer used, its memory will be claimed back for later use. GC do more than that, by trying to compact the “free” memory – so it’ll move (via copy and delete) the survived objects next to each other, therefore you’ll be a big, continuous free memory. This helps improving performance in upcoming allocations, but only until a point. If the objects are too big, then the costs of moving the objects around might outweigh the benefits. Microsoft did a bunch of performance test and they decided that 85000 bytes is the break point, where the costs are bigger than the performance gain. Then we have LOH, where the memory is almost never compacted.
I’ve seen this more than once, and this can be quite tiresome to fix the problem(s) after that. So here the TL;DR: If you are installing Find.Commerce to Commerce Manager, you are doing it wrong.
You’ll probably end up in the error like this
While loading .NET types from "EPiServer.Find.UI" the following error(s) was reported:
- System.IO.FileNotFoundException: Could not load file or assembly 'EPiServer.Cms.Shell.UI, Version=184.108.40.206, Culture=neutral, PublicKeyToken=8fe83dea738b45b7' or one of its dependencies. The system cannot find the file specified.
File name: 'EPiServer.Cms.Shell.UI, Version=220.127.116.11, Culture=neutral, PublicKeyToken=8fe83dea738b45b7'
=== Pre-bind state information ===
LOG: DisplayName = EPiServer.Cms.Shell.UI, Version=18.104.22.168, Culture=neutral, PublicKeyToken=8fe83dea738b45b7
LOG: Appbase = file:///C:/EPiServer/FindSearchProvider/backend/
LOG: Initial PrivatePath = C:\EPiServer\FindSearchProvider\backend\bin
Calling assembly : EPiServer.Find.UI, Version=22.214.171.12448, Culture=neutral, PublicKeyToken=8fe83dea738b45b7.