logo标签列表

ASP.NET MVC性能

asp.netasp.net-mvcperformancewebforms
102

我发现有一些疯狂的说法，声称ASP.NET MVC比ASP.NET WebForms快30倍。实际上有什么性能差异，是否进行过测量，以及性能优势是什么。

这将帮助我考虑从ASP.NET WebForms迁移到ASP.NET MVC。

20
自从WebForms问世以来，我再也不愿意回去了！MVC已经抢走了我的心 - 而且这个网站在Beta 5上运行得非常棒！ - Jarrod Dixon
2
这个问题为什么要进行那么多次的版本回滚？ - Nick
@Nick：OP正在撤销任何编辑，并删除任何解释它们的评论。 - GEOCHET
@Rich B：没错，他删除了我大约5条评论。 - George Stocker
2
现在我们即将发布MVC3，因此需要更新。 - Andrew Lewis
14个回答
69
我们尚未进行足够的可扩展性和性能测试以得出任何结论。我认为ScottGu可能正在讨论潜在的性能目标。随着我们向Beta和RTM推进，我们将在内部进行更多的性能测试。但是，我不确定我们在发布性能测试结果方面的政策是什么。
无论如何，任何这样的测试都需要考虑真实世界中的应用程序...
13
既然MVC已经发布了，有没有发布性能结果的更新？ - chris
6
只是投票支持一下，因为之前的 5,999 声望值实在太刺眼了 :( - Damien
2
到现在为止，你肯定已经有一些数字了。想要更新你的答案吗？或者你发现那个讨厌的政策禁止了吗？ - tvanfosson
7
数字是42。:) 总的来说，我们的数字可能对实际应用程序无用，因此通常不会公开。但是，我知道微软的其他团队正在构建大型网站，他们展示了令人满意的数字。换句话说，任何性能问题更有可能是由于程序员错误而不是框架本身的问题。通常与数据库和外部服务的交互是罪魁祸首。 :) - Haacked
真的！请更新一下！也许不是基准测试，但是简短的想法，它们是否相当，还是MVC在性能上更好一些？ - gideon
48
我认为这将是一个难以明确回答的问题，因为很多取决于A)你如何实现WebForms应用程序，以及B)你如何实现MVC应用程序。在它们的“原始”形式中，MVC可能比WebForms更快，但多年的工具和经验已经产生了许多构建快速WebForms应用程序的技术。我愿意打赌，一位资深的ASP.NET开发人员可以制作出与任何MVC应用程序速度相当甚至可以达到可忽略的差异的WebForms应用程序。

真正的区别-正如@tvanfosson所建议的那样-在于可测试性和清晰的SoC。如果提高性能是您的主要关注点，我认为这不是跳出WebForms并开始在MVC中重新构建的好理由，至少在尝试了优化WebForms的可用技术之前不是。

很棒的回答，Todd（对于一个开发者布道师来说，实际上有一个务实的回应是多么令人惊讶）。你唯一做错的事情就是在原始实现中，WebForm确实更快。 - Chris Marisic
42

通过消除视图状态并使其可编程处理提交的输出，它将我其中一个页面的有效载荷从2MB减少到200k

仅仅是大小减小了，尽管处理相同，也能大幅提高每秒连接和请求速度。

31
即使没有使用MVC，你也可以修复那个讨厌的大viewstate问题。 - Andrei Rînea
1
只是为了阐述，ViewState可以在页面级别或web.config中关闭。 - bbqchickenrobot
8
是的，但在MVC中，它是一个理智的默认设置，而不是一个设计决策，强迫您离开所有控件和声称可以在Web Forms上正常工作的供应商，通过移除其骨干使Web Forms“失效”。我并不反对你可以重新编写那个页面，但整个应用程序没有视图状态会更好。 - DevelopingChris
那么，您不认为将整个应用程序移植到MVC而不是在web.config中关闭视图状态是您最糟糕的决定吗？不，ViewState不是支柱。只有您进行了研究后，ViewState才可以保存在缓存和会话中。 - Simple Fellow
29
我认为很多人认为WebForms本身就很慢或资源密集，这是错误的观点。在我被要求优化WebForms应用程序的9次中，很多时候应用程序作者都误解了视图状态（viewstate）的目的。我不是说视图状态完美无缺，但滥用它实在太容易了，正是这种滥用导致了臃肿的视图状态字段。
这篇文章对我理解许多这些滥用问题有着非常宝贵的帮助。https://weblogs.asp.net/infinitiesloop/truly-understanding-viewstate 为了在MVC和WebForms之间作出有效比较，我们需要确保两个应用程序都正确使用架构。
14

我的测试显示，MVC在请求每秒方面比WebForms快2倍至7倍不等，但这取决于您构建WebForms应用程序的方式。如果只有“hello world”文本且没有任何服务器端控件，则MVC大约快30％至50％。

12

对我来说，MVC真正的“性能”提升是增加了应用程序的可测试表面。在WebForms中，应用程序中有很多难以测试的部分。而在MVC中，变得可测试的代码量基本上翻了一倍。基本上所有不易于测试的内容都是生成布局的代码。现在，包括填充视图中实际使用数据的逻辑在内的所有业务逻辑和数据访问逻辑都可以进行测试。虽然我希望它也更具性能表现——页面生命周期大大简化，更易于网络编程——但即使它与WebForms相同或稍慢，从质量的角度来看，也值得切换。

我真的很想知道为什么有人对这个答案进行了负评。 - tvanfosson
我的感觉是它可能会被踩，因为一个良好设计的ASP.NET Web Forms应用程序与MVC应用程序一样可测试。我开发两者的经验是，MVC强制您进入一个干净的编程模型（在我看来这是它最大的优点之一）。Web Forms让您做更懒的事情，但仍然可以在Web Forms中拥有相同可测试的表面。无论如何，这是我的猜测。 - dudemonkey
Razor视图字面上鼓励在视图中嵌入代码。这是不可测试的，也不利于关注点分离。仅仅因为MVC让你编写控制器，并不意味着如果你不知道你在做什么，你就不能将其混乱起来。 一位熟练的开发人员将从WebForms（或更多）中获得与MVC几乎相同的“可测试表面”，并且将获得同样出色的性能。 - Richard Hauer
@RichardHauer 当我写这篇文章时，这实际上是不准确的，但他们在这方面已经有所改进。既然WebForms似乎在.NET Core中没有未来，这似乎是无关紧要的。 - tvanfosson
@tvanfosson 同意 - 现在这个问题已经没有意义了。不确定您认为哪一部分不正确，也许您反对我使用“字面上”的说法？无论如何，带有TagHelpers的新版本MVC确实有助于打破将代码放入布局的习惯，这可能最终使它对我起作用。当然，赞赏这篇文章已经相当古老了，但即使在当时，构建良好的WebForms表单也非常快速，没有MVC的“魔法连线”，也没有任何嵌入视图中的代码。 - Richard Hauer
@RichardHauer 当我写这篇文章时，WebForms的更改允许依赖注入和增加可测试性还不存在。 Code behind 本质上是不可测试的。你可以将大量代码移动到库中进行测试，但总会有一些代码无法测试 - 比如数据绑定。 - tvanfosson
7

我认为问题在于，无论ASP.Net MVC比旧的WebForms更快多少，它都不会有太大的区别，因为大部分时间都用在了数据库上。大多数情况下，你的Web服务器将只占用0-10%的CPU使用率，只是在等待数据库服务器的响应。除非你的网站受到极大的访问量，并且你的数据库非常快速，否则你可能不会注意到很大的差异。

你的用户可能会 - 没有视图状态。 - UpTheCreek
6
我能找到的关于早期ASP.NET MVC开发的唯一确切数字是这个论坛帖子中提到的：

http://forums.asp.net/p/1231621/2224136.aspx

Rob Connery本人在某种程度上证实了ScottGu所声称的ASP.NET MVC每秒可以处理8000个请求的说法。

也许Jeff和他的团队可以从开发这个网站中给出一些提示。

3
与公认观点相反，优化的Webforms在原始性能方面完全超越了MVC。Webforms已经针对服务HTML的任务进行了超级优化，比MVC更久远。

有关指标，请参见http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=db。

在每个比较中，MVC都位于列表的中下/下上排名，而优化的Webforms使用则位于中上/上下排名。

有一个轶事，但是这些指标非常严肃，www.microsoft.com是由Webforms而不是MVC提供服务。这里是否有人认为如果MVC从经验上更快，他们不会选择MVC？

2

这个问题其实很难回答。MVC默认使用Web Forms视图引擎，但可以配置为使用任意数量的自定义视图引擎，因此如果您想要性能比较，就需要更具体地说明。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接