We are building a site with .NET DXA 1.5 and SDL Web 8.
I have a problem where images seem to be taking a long time to load (between 300ms and 4s) where different images were loading in different times on different requests. After trouble shooting all the caching I was a bit stumped.
I thought this was due to the CID service so I removed that from the project by changing the MediaHelper to be BaseMediaHelper instead of ContextualImageHelper in the Dependency Injection configuration.
We found that our app was much more stable as the CID service was not falling over every few hours but in terms of image load times this made no difference.
Analysing the requests with failed request tracing revealed that the AspNetSessionDataEnd event seemed to be blocking requests which seemed strange since we are not using Session directly in our application anywhere.
I had a look at the web.config and noticed that "runAllManagedModulesForAllRequests" was set to true.
So I added the following config to remove the session module and the image load times are now acceptable.
<modules runAllManagedModulesForAllRequests="true"> <remove name="Session" /> <add name="AmbientFrameworkModule" type="Tridion.ContentDelivery.AmbientData.HttpModule" preCondition="managedHandler" /> <!-- This module can be enabled if you use the ContextualMediaHelper implemention Refer to the IMediaHelper implementation mapping in your unity configuration. <add name="ContextualImageProxyModule" type="Sdl.Web.Context.Image.Proxy.ContextualImageProxyModule" /> --> <add name="DxaStaticContentModule" type="Sdl.Web.Mvc.Statics.StaticContentModule" /> </modules>
However, I am not really comfortable with removing Session as we may need to use the session later. I'm not really sure what is causing the session to block in this way but I am very interested to figure out why.
Stanger still, we have a DXA .NET 1.3 site running from Web 8 which is live and not exhibiting this issue. I can't see any significant differences in the DxaStaticContentModule between these versions.
Has anyone else encountered this behaviour or explain what we're seeing or a way to debug the Session blocking requests like this?