views:

103

answers:

1

Hi

I have an asp.net view/page (dynamic) that is built up of nested Html.RenderPartials. The view is sent an appropriate viewmodel to render.

Firebug says the GET response for the HTML is 9.89 secs for 9.5KB. To compare the FAQ page (static html) of the same site is 1.3 secs for 17K.

At first I thought it was the SQL Entity back end slowing things down due to the complexity of the viewmodel but it seems to construct the viewmodel in less than 1 sec according to my logs.

Any ideas why the MVC view is taking so long to render please and how I can speed this up? I'm considering partial loading via ajax.

(btw I Gzip and use CDN's etc - I have yslowed the whole site to death)

Edit:

Added timers (Stopwatch) to OnActionExecuting/OnActionExecuted and OnResultExecuting/OnResultExecuted.

09/12/2010 18:39:20: Controller: Profile Action: Index Elapsed time: 680.6431 - Action

09/12/2010 18:39:29: Controller: Profile Action: Index Elapsed time: 9202.063 - Result

9 seconds for the framework to render the view.

+1  A: 

Problem Solved

Firstly thanks to you all for your suggestions. I followed each suggestion again and again until I found the issue. This is what was wrong, and maybe someone could clarify for others.

VS2010 Performance Wizard was saying that each object being passed to the PartialViews was taking up huge CPU time and I presumed it to be the partial as I have read they may have issues.

foreach (ProfileComment item in Model)
{
    Html.RenderPartial("UserActivityComment", item);
}
...
Friends friend = Model.Friends.Where(e => e.ID == activity.ActionID).FirstOrDefault();
if (friend.FriendsProfile.UserName != Page.User.Identity.Name)
{
    Html.RenderPartial("UserActivityFriend.ascx", friend);
}

The ProfileComment and Friends object (plus others) are part of a ViewModel I generate and pass to the page. Now the VM is generated via the Entity Framework in less than 0.3 secs So I presumed all was fine with the VM.

The huge delay came when I wanted the view to Process it. The Model in the 'for loop' was flagged, and so was FirstOrDefault by the Performace Wizard.

Hmm strange, the model is constructed rapidly but not processed rapidly. Solution:

_entities.Friends.MergeOption = MergeOption.NoTracking;
_entities.ProfileComment.MergeOption = MergeOption.NoTracking;

I think the issue was extracting the object from the VM to send to the partial as it was also wanting to maintain entity management for relationships.

More info at Aia Research

and blogs.microsoft.co.il/blogs/gilf/archive/2009/02/20/disabling-change-tracking-in-entity-framework.aspx

Please feel free to expand on this in more detail. Btw the performance increase was huge!

Anthony