0

I am currently trying to analyze a performance issue where an ASP.NET MVC razor view renders very slowly: it takes 40+ seconds to return a response to the browser. This issue does not always occur: usually the page loads in ~1/2 seconds.

Below is an image of a part of a MiniProfiler trace made of said page when it is loading slowly. The column on the right is the time passed since the start of the request, and the trace shows large jumps of several seconds there during the rendering of the razor views. What I don't really understand, is why the time in the other 2 columns ("duration (ms)" and "with children (ms)") does not reflect these multi second delays: I'd expect to see large numbers there as well.

What also jumps out at me is the fact that the large delays appear to occur when doing "Find: EditorTemplates/..." steps. Note that these templates do not exist (side note: I don't explicitly try to render these editor templates, but searching for them seems to be caused by the kendo mvc grid on the page). Could the large delays be caused by waiting on disk I/O to establish that these files do not exist? If so: how could this only occasionally take multiple seconds and normally complete relatively quickly?

How should I interpret these results and what could be the cause of the multi second delays?

mini profiler trace

TC.
  • 4,133
  • 3
  • 31
  • 33

1 Answers1

0

Your problem sounds similar to what we had recently: The first call of every single page took ages (a page is something like /Login, /Templates, /Files and so on). Every consecutive call of the very same page was way faster. The issue was that whenever a new page was called it had to be compiled first. The compiled assembly was cached, so next time it was faster.

We build our project with the target Clean and Build. Afterwards we publish it with the following parameters for MSBuild:

/t:WebPublish
/p:Configuration=Release 
/p:WebPublishMethod=FileSystem
/p:publishUrl=%build.dirMSBuild%\projectName
/p:PrecompileBeforePublish=true 
/p:UseMerge=true 
/p:SingleAssemblyName=AppCode
/p:VisualStudioVersion=16.0
/p:DeleteExistingFiles=true 
/p:DebugSymbols=false 
/p:ExcludeApp_Data=false

The most important flag here is PrecompileBeforePublish which makes sure that the views are build during the project build process. Now every page loads almost instantly, even when called for the first time.

Carsten Franke
  • 1,649
  • 2
  • 13
  • 30