For starter this job should be run manually, not automatically, only if you have problems like if you update a product's image but its thumbnail is not refreshed.
(most probably it will be out contents but) any other reason in your knowledge for this kind of bad performance? is 63039 a lot?
It will simply iterate over your assets and clear any thumbnails on them, then patch the asset to trigger creation of new thumbnails. So if you have many assets and multiple thumbnail properties on your media content types, then yes that will be a lot to clear and yes it will be slow
Make sense, do you see the involvement of localization provider also during this process? as I have seen a rise in queries to DB Localization provider also.
Any Help, how this can improve? Does anyone else have the same issue?
It might be just coincidence but a few months back we upgraded from
CMS 11.8.0 to CMS 11.11.2,
Forms 4.1.20 to 4.23.0
DBLocalizationProvider 4.3.3 to 5.3.0
When Editors started having an issue On Loading EPiServer Editor Area after the upgrade. Editor Area was inaccessible after a week or more of Application Recycle/Release and was not accessible until we recycle application again, this was a recurring issue from a couple of months now.
I have investigated this issue from the last few days and collected the following figures
Queries mentioned here was taking 45% and more DTU
I run SQL Profiler and saw following SP is called editDeletePageCheck, during this job run and that SP calls internally another SP 'editDeletePageCheckInternal'
CPU Usage on DB was more than 80% with the current DB Plan
Sometimes CPU Usages was not coming down even after a few hours when the job is finished
This behaviour and figures can be reproduced all the time by running this job.
What time this job is taking for us on Production is as below
DateDurationStatusServerMessage