ASP.NET MVC性能
我发现一些疯狂的言论，即ASP.NET MVC比ASP.NET WebForms快30倍。有什么实际的性能差异，已对此进行了测量以及性能上的好处是什么。
这是为了帮助我考虑从ASP.NET WebForms迁移到ASP.NET MVC。
解决方案
回答
Rick Strahl对什么是生病的ASP.NET Web窗体中的ASP.NET MVC性能有一些想法。
回答
我可以从早期的ASP.NET MVC开发中找到的唯一具体数字在此论坛线程上：
http://forums.asp.net/p/1231621/2224136.aspx
Rob Connery本人某种程度上证实了ScottGu声称ASP.NET MVC每秒可以处理8000个请求的声明。
也许Jeff和他的工作人员可以从他们对该网站的开发中得到一些提示。
回答
我们没有执行得出任何结论所必需的可伸缩性和性能测试。我认为ScottGu可能一直在讨论潜在的绩效目标。随着我们向Beta和RTM迈进，我们将在内部进行更多的性能测试。但是，我不确定我们对发布性能测试结果的政策是什么。
无论如何，任何此类测试确实都需要考虑现实世界中的应用。
回答
仅通过消除viewstate并使它在编程上可承受与提交的输出一起使用，就将我的页面从2MB有效负载减少到200k。
即使处理的大小相同，单独的大小也将极大地提高每秒的连接数和请求速度。
回答
真的没有办法回答这个问题。 MVC默认情况下默认使用Web窗体视图引擎，并且可以配置为使用任意数量的自定义视图引擎，因此，如果要进行性能比较，则必须更加具体。
回答
我的测试显示，在MVC上，req / sec的响应速度提高了2到7倍，但这取决于我们构建Webforms应用程序的方式。仅带有" hello world"文本，没有任何服务器端控制，mvc的速度提高了约30-50％。
回答
对我来说，MVC真正的"性能"改进是增加了应用程序的可测试范围。有了WebForms，许多应用程序很难进行测试。使用MVC，可测试的代码量基本上翻了一番。基本上，所有不容易测试的是生成布局的代码。现在，我们所有的业务逻辑和数据访问逻辑-包括填充视图中使用的实际数据的逻辑-都可以进行测试。虽然我希望它也能表现得更好-页面生命周期被大大简化并且更适合Web编程-即使它相同或者稍微慢一点，从质量的角度来看，还是值得切换的。
回答
我认为这将是一个很难回答的难题，因为很大程度上取决于A)如何实现WebForms应用程序，以及B)如何实现MVC应用程序。以"原始"形式，MVC可能比WebForms快，但是多年的工具和经验已经产生了许多用于构建快速WebForms应用程序的技术。我愿意打赌，一个高级ASP.NET开发人员可以生产可以与任何MVC应用程序的速度匹敌的WebForms应用程序，或者至少可以忽略不计。
@tvanfosson建议的真正区别在于可测试性和干净的SoC。如果我们最关心的是提高性能，那么我认为这不是迁移WebForms并开始在MVC中重新构建的重要理由。至少直到我们尝试过用于优化WebForms的可用技术为止。
回答
我认为许多认为WebForms本质上很慢或者占用大量资源的人都将责任归咎于错误的位置。当我被引入优化Webforms应用程序时，有10的9倍有很多应用程序作者误解了viewstate的目的。我并不是说viewstate是完美的或者任何东西，但是滥用它实在太容易了，正是这种滥用导致了膨胀的viewstate字段。
这篇文章对帮助我理解许多此类滥用无价。 http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/truly-understanding-viewstate.aspx
为了在MVC和WebForms之间进行有效的比较，我们需要确保两个应用程序都正确使用了体系结构。
回答
大约一年前，我开始在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应用程序？那就是我想要的！
我鼓励更多的人尝试一下。
回答
我认为这里的问题是，无论ASP.Net MVC比旧的Webform快多少，它都不会起作用，因为大部分时间都在数据库中。在大多数情况下，Web服务器将仅在数据库服务器上等待0-10％的CPU使用率。除非我们在网站上获得大量点击，并且数据库非常快，否则我们可能不会注意到很大的不同。
