GlassMapper CPU Utilization issues

[gredkar]

At Informa We are running a Sitecore solution on which we are observing performance issues lately. During the tests, we are observing the page load times to be higher than expected and we tried to optimise the website using caching wherever possible.

Upon further investigation of the issue with Sitecore technical support team using trace tools, they observed that maximum time circa 80% is being spent within Glass Mapper’s LoadValue method (Glass.Mapper.Pipelines.ObjectConstruction.Tasks.CreateInterface.InterfacePropertyInterceptor.LoadValue(AbstractPropertyConfiguration).

Here are a few screen grabs from trace analysis are attached in the word document where we can observe this method to be most expensive one:

GlassMapperScreenshots.docx

Also during the load tests of the application, we have observed high CPU utilization on webservers and traces from worker process also indicate similar observations on maximum time being spent while executing the same method.

We are trying to implement GlassMapper caching at POCO level wherever html caching does not serve the purpose, but will appreciate any other suggestions which could help us solve the problem.

[cardinal252]

Hey @gredkar, could you send the trace files to me if thats possible ?? nathanael.mann@cit-design.co.uk.

I wouldn't recommend caching to solve that sort of issue. I think there are many other approaches. The highest likelihood is that its the result of a lazy load call that is causing a long running process. I am 99% sure Glass is just showing as the culprit cos it is responsible for the proxy that is allowing the call to take place.

[mikeedwards83]

Hi

Can you use the diagnostic tools in Glass to identify which models are slow:
http://www.glass.lu/Mapper/Sc/Documentation/Diagnostics

This may help you track down which models /properties are causing the problem.

Mike

[sanjeevpurohit]

Update: Mike, we have been able to get this working and will share our findings from the logs shortly.
For now, we have managed to get it working by setting config.EnableLazyLoadingForCachableModels = true as we were facing issues when we set is to false.
Can you please advise if that's how we should be setting this?

---

Thanks, Mike. We tried enabling the logs and checked for some Models which were taking time. However, we ran into this error:
"Model too deep. Potential lazy loading loop. Type requested glassmapper error "

Reading the documentation here, we adding the following which has resulted in content not being mapped. Can you please advise if we are doing something wrong here?
Code Snippet:

var config = new Glass.Mapper.Sc.Config();

        if (Sitecore.Configuration.Settings.GetSetting("GlassMapperDebug").Equals("true"))
        {
            config.Debug.Enabled = true;

            //set a new Threshold for the model timer:
            config.Debug.SlowModelThreshold = int.Parse(Sitecore.Configuration.Settings.GetSetting("GlassMapperModelTimer"));
        }
        config.EnableLazyLoadingForCachableModels = false;
        var dependencyResolver = new DependencyResolver(config);           
        var factory =
          dependencyResolver.ObjectConstructionFactory as AbstractConfigFactory<AbstractObjectConstructionTask>;
        factory.Remove<Glass.Mapper.Pipelines.ObjectConstruction.Tasks.DepthCheck.ModelDepthCheck>();

        // add any changes to the standard resolver here
        return dependencyResolver;

[cardinal252]

It looks likely that you have one or more of the following:

i) You have a class being used somewhere that either has looping issues (ie: parent mapping child mapping parent)
ii) You have a class being used in a pipeline that is forcing the mapping of too many fields (something like httpRequestBegin / mvc.renderRendering)
iii) You are generally overmapping - possibly to a large base class or something similar.
iv) You are mapping to a query / children that is bringing back a lot of unnecessary additional information
v) You are mapping to a query / children that is not lazy loaded

Glass has undergone extensive performance testing and most of the cpu utilisation you are seeing is from getting properties from your model which is in turn getting fields / children from Sitecore.

I am more than happy to help you further, but this would have to be on a consultancy basis since it is an issue specific to your solution and also clear from the trace that the majority of work being done from the method you are questioning is in fact from the Sitecore APIs (particularly the render field pipeline which is likely to be rich text fields).

If you wish to discuss consultancy further, please don't hesitate to reach out to myself or Mike