Hi Claude

When you 'sort' you are essentially triggering a 'save' action on each item in the list (as a SortOrder number is stored in the database next to each item, and sorting will update this number for each item in the list)

So have had issues before if an individual item can't be saved, we had a custom 'locking checkout' mechnanism, and locked out items couldn't be saved, and hence couldn't be sorted...

.. so it's worth checking if you have any code handling, saving or saved events...

... but with 500 items it might just be timing out?

Does sort work ok on a smaller subset of items?

when the sort errors, is there any further information in the browser console?

How does your SQL Server instance perform during the sort (are you using SQL Server or SQL CE?) - is it maxed out 100% cpu?

How is your SQL server index fragmentation?

Anyway lots of questions, no answers - hopefully knowing that Sort - triggers Saves on everything will lead you to a solution!

regards

Marc

Hi Mark

Thank you for the quick reply.

We have indeed one event registered on the publish event

ContentService.Published += ContentService_Published;

private void ContentService_Published(IContentService sender, ContentPublishedEventArgs e)
        {
            if (e.PublishedEntities.Where(x => x.ContentType.Alias == "shopLocation").Any())
            {
                _runtimeCache.ClearByKey($"{nameof(ShopLocatorController)}_Get_");
            }

            if(e.PublishedEntities.Where(x => x.ContentType.Alias == "tvChannel").Any()) {
                _runtimeCache.ClearByKey($"{nameof(TvChannelController)}_Get_");
            }
        }

We have a separate cache for sertain ContentTypes that are used in a API. This cache gets cleared if such a Node will be saved. I did observe it and it did not seam to block the performance.

What i forgot to mension, is that also response time suffers a lot when performing a sort operation in the backoffice.

In the meantime I upgraded to latest Umbraco Version 8.17.0

Now the Sorting still takes long, but results not in an error. So it works. Unfortunatly the Response Time (more than a minute) is still very poor during this operation.

The DTU usage (azure) is locally then up to 100% also CPU is rising very similar towards 100%

So I run that on basic plan for test. Also production is running into the same problem, but without reaching the same level of usage (DTU and CPU). Of course Production has a better Plan and therefore more ressources.

So you would suggest to increase DB Plan? should i go with V-Core based or DTU-based?

Hi Claude

As you can see sorting 500 items will trigger a storm of individual SQL requests, so if your SQL Azure is 100% during the sort... then yes that is the limiting factor and explains the slowness.

Scaling up, will mask the problem and allow the sort to complete more quickly...

... but the bigger question is... do you need to sort 500 items in the backoffice? could the content be structured into folders? eg having month/year folders or current / archive, so there is a smaller number to sort for new items? Difficult to know without the context!!

regards

Marc

is working on a reply...