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.
Thanks for sharing these finding. We have analysed the problem and proposed solution, and we find that making changes to this behavior has a big risk of breaking existing implementations in ways that are hard to mitigate completely without losing the performance gain. We will try to pick this back up for the next major release.