缓慢的嵌套 RenderPartial 响应时间

发布于 2024-09-18 14:33:39 字数 620 浏览 8 评论 0原文

我有一个由嵌套的 Html.RenderPartials 构建的 asp.net 视图/页面(动态)。视图被发送到适当的视图模型来渲染。

Firebug 表示,9.5KB 的 HTML GET 响应时间为 9.89 秒。 比较同一站点的 FAQ 页面(静态 html),17K 的时间为 1.3 秒。

起初我以为是 SQL 实体后端由于视图模型的复杂性而减慢了速度,但根据我的日志,它似乎在不到 1 秒的时间内构建了视图模型。

有什么想法为什么 MVC 视图需要这么长时间才能渲染以及如何加快速度吗?我正在考虑通过ajax 进行部分加载。

(顺便说一句,我使用 Gzip 并使用 CDN 等 - 我已经减慢了整个站点的速度)

编辑:

向 OnActionExecuting/OnActionExecuted 和 OnResultExecuting/OnResultExecuted 添加计时器(秒表)。

09/12/2010 18:39:20:控制器:配置文件操作:索引 已用时间:680.6431 - 操作

09/12/2010 18:39:29:控制器:配置文件操作:索引 已用时间:9202.063 - 结果

9 秒渲染视图的框架。

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

甜心小果奶 2024-09-25 14:33:39

问题已解决

首先感谢大家的建议。我一次又一次地遵循每个建议,直到找到问题为止。这就是问题所在,也许有人可以为其他人澄清。

VS2010 性能向导说传递给 PartialViews 的每个对象都占用了大量的 CPU 时间,我认为它是部分的,因为我读到它们可能有问题。

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);
}

ProfileComment 和 Friends 对象(以及其他对象)是我生成并传递到页面的 ViewModel 的一部分。现在,虚拟机是通过实体框架在不到 0.3 秒的时间内生成的,所以我认为虚拟机一切都很好。

当我想要视图处理它时,出现了巨大的延迟。 “for 循环”中的模型已被标记,性能向导也标记了 FirstOrDefault。

嗯,奇怪的是,模型构建得很快,但处理得不够快。 解决方案:

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

我认为问题在于从虚拟机中提取对象以发送到部分,因为它还希望维护关系的实体管理。

更多信息请访问 Aia Research

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

请随意对此进行更详细的扩展。顺便说一句,性能提升是巨大

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!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文