We love feedback from you on our products and the problems in your daily work that you would like us to solve. Please describe the challenge you're encountering and your desired outcome. Be as detailed as possible.
For technical issues or bugs please head to Support or our Developer Community. You can assign up to 20 votes in total. Thank you for your feedback.
Status explanation: 'Future Consideration' = Continuing to collect further feedback, not planned at this time. 'Investigating' = Prioritized for deeper customer and feasibility investigations ahead of planning development.
Reducing the startup time can mean that when sites are restarted either after a deploy or just a manual restart the unavailability time is reduced. When code changes are made this becomes especially important.
When reviewing the startup time for an optimizely installation with around 250 content types, a lot of time appears to be spent in the ModelSyncInitialization module.
The Initialize method calls ContentTypeModelScanner.Scan which calls ContentTypeModelRegister.AnalyzeProperties. which calls the ContentTypeModelRegister. SetStateForPropertyDefinitionModels method which calls the ContentTypeModelRegister.ValidateChangeOfModelType method. This method appears to be the cause of the slow startup time observed.
The ValidateChangeOfModelType method calls PropertyDefinitionType.ResolveType which likely has locking taking place inside of it. The items which have significant performance degradation changes run-over-run, which suggests it’s some form of locking.
By largely rewritting the ModelSyncInitialization to further the parallelization using Tasks by lifting loops inside of the existing Parallel.ForEaches outside of the Parallel.ForEach as well as passing in the PropertyDefinitionType object into the ValidateChangeOfModelType method and retrieving these serially rather than in parallel.
Startup times were observed to change from around 30 seconds to 3 seconds.
Suggest the product adopt these or similar changes, to improve startup time.