Take the community feedback survey now.
Take the community feedback survey now.
That does indeed sound weird. How does the similar request look when invoked from a page?
Those requests does not use Find or another index. It simply uses the GetChildren method from the content loader. Do they have many pages below the start page (I assume you ID 4 is a start page).
Does it also time out on local host?
Try to check the logs to see if there is any information. If you are unable to figure out anything from the logs, try increasing the timeout time.
I hope this article will help to increase the timeout
https://docs.developers.optimizely.com/content-management-system/docs/configuring-cms-user-interface
It works just fine both on my local machine and on our test-server, which makes me suspect that there's something with the Azure-setup that's causing this. The request from a page looks just fine and loads rather quickly (as expected). They don't have that many pages under the start page so it shouldn't slow down the request.
The logs doesn't give anything, which is frusrating, and since it works just fine on my local machine plus the test-server I can't debug it in a proper manner.
The timeout that occurs is the Azure-timeout (we get a 504 gateway timeout) so it's not the code that timeouts but I can always try to raise the preview timeout. We've tried raising the gateway timeout but that caused the server to crash when multiple editors were using it.
Hello Alexander,
Can you share more information about the structure of your content items and the version of the CMS you're using?
Have you registered any code onto the content loading events? Are you using the A/B Testing Add-on for Optimizely CMS? I've observed that this addon causes issues with performance in the content loading events in DXP.
Hi Mark
The site used EpiServer.CMS 12.33.1, .net8. No custom loading events or A/B-testing. It's a five-language site and the structure can be a bit messy unfortunatelly since editors doesn't always create language versions of a page but instead create a new page instead.
Hi Alexander,
Just now today, Optimizely has delisted version 12.33.2 but that might not be an issue since you were on 12.33.1 but worth checking.
Interestingly, the release note (1st) points to some loading state
Did you try upgrading to 12.33.3 ?
I would also look for any custom EditorDescriptor that loads along with modal causing probable issues.
U've upgraded to 12.33.3 and it seems that some request are indeed a little faster but the initial call is still timeing out after 20 seconds (because if Azure 504 timeout)
I'm curious about /EPiServer/cms/Stores/contentstructure/4?typeIdentifiers=episerver.core.pagedata&allLanguages=true&ownerContentLink=32545 though. ID 4 is the "content asset"-folder and if I RDP into the Azure VM that request takes around 58 seconds to be called.
I'm not sure why the code tries to filter pagedata with the content asset-folder as starting point though. Seems a bit odd? It doesn't seem to cache the list eather since if I reload the page and open the page modal again it takes around a minute to load the page three into the modal again.
So I've solved it.
Turned out that the blobs-folder had some strange permissions issues (a lot of sub folders refused to inherit the permissions from blob-folder) so for a very long time (probably a year or so) neither "Remove Abandoned BLOBs" nor "Remove Unrelated Content Assets" scheduled job could run properly (getting access denied errors). After fixing that issue I could re-run those jobs and number of folders in blob-folder decreased from ca 1 150 000 folders to around 500 000 folders and many, many thousands of assets folders were removed.
So in the end, the problem was a bloated database because necessary scheduled jobs didn’t execute properly.
On my clients live-server (an azure VM) the "Create link" modal times out after 20 seconds when opening the page three modal in the "Create link" dialogue. It's this call that timesout:
/EPiServer/cms/Stores/contentstructure/4?typeIdentifiers=episerver.core.pagedata&allLanguages=true&ownerContentLink=32545
They don't have find on that site, so it's epis internal search that's being executed.
The strange thing is that it works just fine when opening that modal from a page type but for some reason it crashes when trying to edit a link inside a block.
Has this happened to anyone else? Of all the sites I've worked on (hosted both on-prem, azure and azure vm) this is the first time this has happened.