Skip to Main Content
Customer Feedback

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 10 votes in total. Thank you for your feedback.

Status Investigating
Product Content Cloud
Categories Technical
Created by Guest
Created on Jul 4, 2022

Improve model sync speed

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.

  • Optimizely
    Martin Ottosen
    Jul 4, 2022

    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.