Import catalog: beware of warning messages

Recently I worked with a support case from a customer. They complained that the catalog import is too slow for them, it took them 6-7 minutes to import 200 entries. Their catalog is about 50k entries, which is not particularly big, but not small neither, and with that rate, it does mean they will have to wait for days for the catalog imported. This is of course not good and I jumped in when I became available. (In the end, I like performance tuning so much that I find it hard to refuse a case like this)

I did try to import their catalog on my development machine – a relatively powerful desktop with Intel Core i7 4790 CPU, 16GB of RAM and 256GB SSD on Windows 10/.NET 4.5.2. Everything went quite well – I achieved a rate of 200 entries per 9-10 seconds, which is, IMO, more than enough. (And this is on Commerce 9, on Commerce 8 then I would suspect it’s 3-4 times slower).

After some conversations with Episerver’s developer support team, it seems that the slowdown only happens with the re-import. I tried it again with re-import. Hmm, something is wrong here. The import is much slower and it eventually stops at some points. The debugger shows that it starts quite well, even faster than a new import (200 entries per 3-4 seconds, a very recent version of Commerce made an improvement of skipping the entries which are not changed to speed up the import), but it slows down by time. Profiling does not show anything obvious, most of the time was spent with loading the MetaObject:s – which is kind of expected.

I was starring at the import tab, and wondering what can be wrong, and suddenly I realized the answer is what I was looking at:

(more…)

Diagnose your Episerver site: find and fix the issues

It’s quite often to see some questions related to issues posted in Episerver World forums. While I (and most of people there) are willing to help, it still takes time for you to write the question and wait for an answer. Sometimes, the answer can be incomplete or even incorrect, because the people answering your question do not have the full context as you do. The truth is, you’re the person who know the most about your site, and you can do something to diagnose it. Those steps below are in the order you should take to diagnose your site:

  • Browser console is your friend. It’s the thing which seemingly ignored the most. When something does not work in Edit UI (CMS) or Catalog UI (Commerce), make sure to open your Browser console and switch to Console tab. If their was a network issue, such as a 500 “Server error” response, make sure to open it. (Right click and choose “Open in a new tab” in Chrome). More often than you might think, it can reveal the underlying problem. If it’s a JavaScript error, how does it look like?
  • Logging is your (another) friend. When something seems to be wrong, check your log file, or turn down your logging level to see if you can see any trace there. In some case, no log found can also be a trace to solve the problem.
  • Does iisreset solve your problem? No I’m not suggesting you to run iisreset every minute on your production site, but it might isolate the problem – if it does, then the problem might relate to cache, or initialization modules. If it does not, well, it can be anything else. But at least it’s not caused by certain things – the key is to narrow down the causes of problem. You can also try to call

ISynchronizedObjectInstanceCache.Clear();

    • if the issue seems to related to the “modern” cache – such as ContentProvider. Note that ISynchronizedObjectInstanceCache does not control everything and iisreset is still the more powerful cache-clearing option.

(more…)