[CMS 8.6.2] Editor interface performance issue


We have a customer experiencing performance issue on editor interface when there is a lot (around 40) of blocks in the content area. It takes 10 seconds to load the all properties view. Although it loads fast while previewing the page. It takes quite a lot of time while working on the all properties view. 

The customer have more than 20,000 blocks in the site. And at least 60% of them are shared blocks and 30-40% are site specific blocks. Customer have rarely used page specific blocks. I know you would be saying why do you have so many shared blocks. Unfortunately, thats how their previous architect built the site and made it worse in longer run.

I am asking your opinion if there is something we can do increase the performance in the short term while waiting to rearchitect the platform in the long run. Please suggest your approach. e.g.

  1. Is there anything we can do using cache? As this is editor interface we are talking about here, do we have ability to alter anything in there?
  2. Is there anything we can do towards indexing the table to make it faster? Although i know epi CMS tables are already indexed and normalized.
  3. Anything else ?

Any advice is appreciated. Thank you in advance.

Jan 10, 2018 18:00

Not sure, but I think you can forget about cache, as the Episerver cache is not used for the editorial interface...

Jan 11, 2018 13:19

I would probably run a profiler and just compare and see what actually takes time. It could be that it's a client issue and not a data issue.
You mention it is fast in preview mode, is it fast when editing on page?

Jan 11, 2018 18:01

@Sebastian, SQL Profiler does not show anything taking time, infact it takes 20ms for SQL query.

Yes, it is fast on preview mode, but onpage is edit is not an option for the nested block in CMS 8.6. I believe it was out of scope until CMS 10. 

In the meantime, we wrote a program to identify all the blocks not in use. We found 40% of the blocks are not in use. After cleaning up the unsed blocks from the site, we observed a 25% increase in performance, which is still not much because it still taking more than 8-9 seconds to load.

After running a profiler on the chrome performance panel, we found most of the times are being consumed on creating dojo components for visitor groups. It looks like the site has 450 visitor groups (I know thats a lot of visitor groups) and editor interface is building the visitor groups menu and applying logics before loading on the all properties view. That is infact creating performance issue. Does anyone have any suggestion if we can restrict applying visitor group before loading blocks in all properties view?


Edited, Jan 11, 2018 18:39
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.