我发现一些疯狂的评论称 ASP.NET MVC 比 ASP.NET WebForms 快 30 倍。真正的性能差异是什么,是否经过测量以及性能优势是什么。

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

有帮助吗?

解决方案

我们尚未执行得出任何结论所需的可扩展性和性能测试类型。我认为 ScottGu 可能一直在讨论潜在的性能目标。随着我们迈向 Beta 和 RTM,我们将在内部进行更多性能测试。但是,我不确定我们关于发布性能测试结果的政策是什么。

无论如何,任何此类测试确实需要考虑现实世界的应用程序......

其他提示

我认为这将是一个很难明确回答的问题,因为很大程度上取决于 A) 如何实现 WebForms 应用程序,以及 二) 如何实现 MVC 应用程序。在“原始”形式中,MVC 可能比 WebForms 更快,但是多年的工具和经验已经产生了许多用于构建快速 WebForms 应用程序的技术。我愿意打赌,高级 ASP.NET 开发人员可以开发出与任何 MVC 应用程序的速度相媲美的 WebForms 应用程序,或者至少实现可以忽略不计的差异。

真正的区别—— 正如@tvanfosson建议的那样- 具有可测试性和干净的 SoC。如果提高性能是您最关心的问题,那么我认为这不是跳槽到 WebForms 并开始在 MVC 中重新构建的好理由。至少在您尝试了优化 WebForms 的可用技术之前是这样。

只需消除视图状态并使其能够以编程方式处理提交的输出,它就将我的一个页面的有效负载从 2MB 减少到 200k。

尽管处理过程相同,但仅凭大小就会在每秒连接数和请求速度方面产生巨大的改进。

我认为,许多认为 WebForm 本质上速度慢或资源密集的人都把责任放在了错误的地方。当我被带去优化网络表单应用程序时,十分之九的应用程序作者在很多地方误解了视图状态的目的。我并不是说视图状态是完美的或者其他什么,但是滥用它太容易了,正是这种滥用导致了视图状态字段的臃肿。

这篇文章对于帮助我理解许多这些滥用行为非常有价值。 https://weblogs.asp.net/infinitiesloop/truly-understanding-viewstate

为了在 MVC 和 WebForms 之间进行有效的比较,我们需要确保两个应用程序都正确使用架构。

我的测试显示 MVC 上的请求/秒增加了 2 倍到 7 倍,但这取决于您构建 Web 表单应用程序的方式。仅使用“hello world”文本,没有任何服务器端控制,mvc 的速度大约快 30-50%。

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

我认为这里的问题是,无论 ASP.Net MVC 比旧的 Webform 快多少,都没有什么区别,因为大部分时间都花在数据库上。大多数时候,您的 Web 服务器的 CPU 使用率为 0-10%,只是在等待数据库服务器。除非您的网站获得大量点击,并且您的数据库速度非常快,否则您可能不会注意到很大的差异。

我能找到的来自早期 ASP.NET MVC 开发的唯一具体数字是在此论坛线程上:

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

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

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

与公认的观点相反,优化的 Web 表单使用在原始性能方面完全杀死了 MVC。Webforms 对于提供 html 的任务进行了高度优化,其运行时间远远长于 MVC。

指标可用于 http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=db

每个比较的 mvc 都位于列表的中下/下上排名,而优化的 webforms 使用则位于中上/上下排名。

对这些指标的轶事但非常认真的验证, 微软网站 由 Webform 而非 MVC 提供服务。这里是否有人相信,如果 MVC 根据经验更快,他们就不会选择 MVC?

这个问题实在是没有办法回答。MVC 默认情况下使用 Web 窗体视图引擎,并且可以配置为使用任意数量的自定义视图引擎,因此如果您想要进行性能比较,则必须更具体。

大约一年前,我开始从事 MVC 工作,我受到了启发,但没有留下深刻的印象。

我讨厌视图状态,并将其视为 ASP.NET 的万恶之源。这就是为什么我不使用它,说实话,你为什么要使用它呢?

我基本上采用了 ASP.NET MVC 框架概念,并以自己的方式构建了它。不过我改变了一些事情。我围绕动态重新编译构建了控制器包装代码或 URL 路由代码。

现在,我什至可以说 ASP.NET MVC 应用程序会更快,具体取决于您使用它的方式。如果您完全放弃 WebForms,您会更快,因为 ASP.NET 生命周期和对象模型非常庞大。

当你写作时,你正在实例化一支军队......不用等等,大量的对象将参与您的视图的渲染。这比在 ASPX 页面本身中表达最少量的行为要慢。(我不关心视图引擎抽象,因为 Visual Studio 中对 ASPX 页面的支持相当不错,但由于代码膨胀或无法更改连接我的应用程序的东西)。

我找到了依靠动态重新编译(System.Reflection.Emit)在需要时发出特殊用途对象和代码的方法。该代码的执行速度比反射快,但最初是通过反射服务构建的。这为我的 MVC 风格的框架提供了出色的性能,但也具有非常静态的类型。我不使用字符串和名称/值对集合。相反,我的自定义编译器服务将重写表单发布到传递引用类型的控制器操作。在幕后发生了很多事情,但是这段代码速度很快,比 WebForms 或 MVC 框架快得多。

另外,我不编写 URL,而是编写 lambda 表达式,这些表达式会转换为 URL,稍后告诉 URL 要调用哪个控制器操作。这虽然不是特别快,但胜过损坏的 URL。就像您拥有静态类型资源和静态类型对象一样。静态类型的 Web 应用程序?这就是我想要的!

我会鼓励更多的人尝试这个。

使用 Visual Studio 创建的项目。一种是mvc4模板,另一种是WebForm(繁体)。当使用 WCAT 进行负载测试时,这就是结果,

MVC4 比 WebForms 慢很多,有什么想法吗?

enter image description here

MVC4

  • 可以获得大约 11 rps
  • 2-cpu 或 4-cpu 服务器的 rps 都相当低

enter image description here

网页表单 (aspx)

  • 可以达到 2500 rps 以上

  • 性能杀手已被发现是 MVC Bata 或 RC 的错误。一旦我删除 Bundles 的东西,性能就会得到改善。现在最新版本修复了这个问题。

性能取决于你在做什么...通常,MVC 比 asp.net 更快,主要是因为 Viewstate 不存在,并且默认情况下 MVC 更多地使用回调而不是回发。

如果你优化你的 Webform 页面,你可以拥有与 MVC 相同的性能,但这将需要大量工作。

此外,它们还有很多 MVC(以及 Webform)的核心内容,可以帮助您提高网站性能,例如组合和缩小 css 和 javascript、对图像进行分组并将它们用作精灵等。

网站的性能很大程度上取决于您的架构。具有良好关注点分离的干净代码将为您带来更干净的代码以及如何提高性能的更好想法。

你可以看看这个模板“Neos-SDI MVC 模板“这将为您创建一个干净的架构,默认情况下具有大量性能改进(检查 Mvc模板 网站)。

enter image description here

我使用一些基本代码做了一个小型 VSTS 负载测试实验,发现 ASP.NET MVC 响应时间比 ASP.NET Webforms 快两倍。上面是附有图的图表。

您可以从这篇 CP 文章中详细阅读此负载测试实验 https://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari

使用 VSTS 和 Telerik 负载测试软件按照以下规格进行测试:-

用户负载 25 个用户。

测试的运行时间为 10 分钟。

机器配置 DELL 8 GB RAM,Core i3

项目托管在 IIS 8 中。

项目是使用 MVC 5 创建的。

假设网络 LAN 连接。所以这个测试暂时不考虑网络延迟。

测试中的浏览器选择了Chrome和Internet Explorer。

测试期间进行多次读数以平均未知事件。本文采用了 7 个读物,所有读物均作为读物 1、2 等发布。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top