我发现一些疯狂的言论，即ASP.NET MVC比ASP.NET WebForms快30倍。有什么实际的性能差异，已对此进行了测量以及性能优势是什么？

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

我们没有执行得出任何结论所必需的可伸缩性和性能测试。我认为ScottGu可能一直在讨论潜在的绩效目标。随着我们向Beta和RTM迈进，我们将在内部进行更多的性能测试。但是，我不确定发布perf测试结果的政策是什么。

无论如何，任何此类测试确实都需要考虑实际应用程序。

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

正如@tvanfosson所建议的，真正的区别在于可测试性和干净的SoC。如果您最关心的是提高性能，那么我认为这不是迁移WebForms并开始在MVC中重新构建的重要理由。至少直到您尝试过用于优化WebForms的可用技术为止。

仅通过消除viewstate并使它在编程上可承受与提交的输出一起使用，就将我的页面从2MB有效负载减少到200k。

即使处理是相同的，单独的大小也将极大地提高每秒的连接数和请求速度。

我认为许多认为WebForms本质上很慢或占用大量资源的人都将责任归咎于错误的位置。当我被引入优化Webforms应用程序时，十分之九的情况是，应用程序的作者在太多地方误解了viewstate的目的。我并不是说viewstate是完美的或任何东西，但是滥用它实在太容易了，正是这种滥用导致了viewstate字段膨胀。

这篇文章对帮助我了解许多此类滥用无价。https://weblogs.asp.net/infinitiesloop/truly-understanding-viewstate

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

我的测试显示，在MVC上，req / sec的响应速度提高了2到7倍，但这取决于您构建Webforms应用程序的方式。仅带有“ hello world”文本，没有任何服务器端控制，mvc的速度提高了约30-50％。

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

我认为这里的问题是，无论ASP.Net MVC比旧的Webforms快多少，它都不会起作用，因为大部分时间都在数据库中。大多数情况下，您的Web服务器将在数据库服务器上等待0-10％的CPU使用率。除非您在网站上获得大量点击，并且数据库非常快，否则您可能不会注意到很大的不同。

我可以从早期的ASP.NET MVC开发中找到的唯一具体数字在此论坛线程上：

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

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

也许Jeff和他的工作人员可以从他们对该网站的开发中得到一些提示。

与公认的观点相反，就原始性能而言，优化的Web窗体用法完全杀死了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默认情况下默认使用Web窗体视图引擎，并且可以配置为使用任意数量的自定义视图引擎，因此，如果要进行性能比较，则必须更加具体。

大约一年前，我开始在MVC中工作，但受到启发但没有留下深刻的印象。

我讨厌视图状态，并认为它是ASP.NET的万恶之源。这就是为什么我只是不使用它，而老实说你为什么呢？

我基本上采用了ASP.NET MVC框架的概念，并以自己的方式构建了该概念。我还是改变了几件事。我围绕动态重新编译构建了控制器包装代码或URL路由代码。

现在，我要说的是，根据您的使用方式，ASP.NET MVC应用程序将更快。如果您完全放弃WebForms，您会更快，因为ASP.NET的生命周期和对象模型非常庞大。

在编写时，您是在实例化一支军队……别等，一大批对象将参与视图的渲染。这比在ASPX页面本身中表达最少行为的速度要慢。（我不在乎视图引擎的抽象，因为在Visual Studio中对ASPX页面的支持是不错的，但是由于代码膨胀或无法更改WebForms，我已经完全放弃了WebForms的概念，基本上已经放弃了任何ASP.NET框架。连接我的应用程序的东西）。

我发现了依靠动态重新编译（System.Reflection.Emit）来在需要时发出特殊目的对象和代码的方法。该代码的执行比反射更快，但最初是通过反射服务构建的。这不仅使我的MVC风格的框架具有出色的性能，而且还具有非常静态的类型。我不使用字符串和名称/值对集合。取而代之的是，我的自定义编译器服务将重写表单发布到传递给引用类型的控制器操作中。幕后发生了很多事情，但是此代码速度很快，比WebForms或MVC框架快得多。

另外，我不写URL，而是写lambda表达式，这些表达式被转换为URL，这些URL以后可以告诉调用哪个控制器动作。这不是特别快，但是可以避免URL损坏。就像您拥有静态类型的资源以及静态类型的对象一样。静态类型的Web应用程序？那就是我想要的！

我鼓励更多的人尝试一下。

使用Visual Studio创建的项目。一个是mvc4模板，另一个是WebForm（传统）。当使用WCAT进行负载测试时，这就是结果，

MVC4比WebForms慢很多，有什么想法吗？

MVC4

• 可以得到大约11 rps
• 无论是2-cpu还是4-cpu服务器，rps都非常低

WebForms（aspx）

• 可以达到2500 rps以上

• 已经发现性能杀手是MVC Bata或RC的错误。一旦我删除了Bundles的东西，性能就会得到改善。现在，最新版本已解决此问题。

性能取决于您在做什么...通常，MVC比asp.net更快，这主要是因为缺少Viewstate，并且默认情况下，MVC与Callback的合作比与Postback的合作更多。

如果优化您的Webform页面，您可以具有与MVC相同的性能，但这将需要很多工作。

此外，它们是MVC（以及Webform）的许多细节，可以帮助您改善网站性能，例如组合和最小化CSS和javascript，对图像进行分组并将其用作sprite等。

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

您可以看一下此模板“ Neos-SDI MVC模板 ”，它将为您创建一个干净的体系结构，默认情况下具有许多性能改进（请查看MvcTemplate网站）。

我用一些基本代码做了一个小的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等形式发布。