ASP.NET MVC性能
我发现一些野蛮的言论，ASP.NET MVC比ASP.NET WebForms快30倍。 有什么真正的性能差异，有没有测量，性能的好处是什么。
这是为了帮助我考虑从ASP.NET WebForms转移到ASP.NET MVC。
我们还没有进行必要的可扩展性和性能testing来得出任何结论。 我认为ScottGu可能一直在讨论潜在的perf目标。 当我们转向Beta和RTM时，我们将在内部进行更多的性能testing。 但是，我不知道我们的政策是发布性能testing的结果。
无论如何，任何这样的testing真的需要考虑真实世界的应用程序…
我认为这将是一个很难回答的问题，因为这将取决于如何实现WebForms应用程序，以及如何实现MVC应用程序。 在他们的“原始”forms中，MVC可能比WebForms更快，但是多年的工具和经验已经产生了构build快速WebForms应用程序的许多技术。 我敢打赌，一个高级的ASP.NET开发人员可以生成一个与任何MVC应用程序速度相媲美的WebForms应用程序，或者至less可以实现微不足道的差异。
正如@tvanfosson所build议的，真正的区别在于可testing性和清洁的SoC。 如果提高性能是您最关心的问题，我不认为这是一个很好的理由在WebForms上跳跃，并开始在MVC中重新构build。 至less在您尝试了可用于优化WebForms的技术之前。
它把我的一个页面从2MB有效负载减less到了20万，只是消除了视图状态，并以编程方式使其能够处理所提交的输出。
即使处理是相同的，单独的大小也会在每秒的连接和请求的速度方面产生巨大的改进。
我认为许多认为WebForms本质上是缓慢的或资源密集型的人将责任归咎于错误的地方。 当我被引入优化一个webforms应用程序时，有10次是9次，应用程序作者误解viewstate的目的的地方太多了。 我并不是说视图状态是完美的或任何其他的，但它是太容易滥用它，这是造成臃肿的视图状态字段的这种滥用。
这篇文章在帮助我理解这些滥用行为方面是无价值的。 http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/truly-understanding-viewstate.aspx
为了在MVC和WebForms之间进行有效的比较，我们需要确保两个应用程序正确地使用这些体系结构。
我的testing显示MVC上的需求量是2x和7x之间，但这取决于您如何构buildWebforms应用程序。 只要有“hello world”文本，没有任何服务器端的控制，mvc大约快30-50％。
Rick Strahl对ASP.NET MVC中的 ASP.NET MVC性能有一些想法。
对我来说，MVC中真正的“性能”改进是增加应用程序的可testing表面。 使用WebForms，有很多应用程序很难testing。 使用MVC，可testing代码的数量基本上翻了一番。 基本上所有不容易testing的是生成布局的代码。 所有业务逻辑和数据访问逻辑（包括填充视图中使用的实际数据的逻辑）现在都可以用于testing。 虽然我期望它的性能更好 – 页面生命周期也大大简化了，而且更适合于网页编程，即使是相同的或者慢一点的，从质量的angular度来看也是值得的。
我认为这里的问题是，无论ASP.Net MVC比旧的webforms多快，都不会有什么区别，因为大部分时间都在数据库中。 大多数情况下，您的Web服务器将占用0-10％的CPU使用量，仅等待您的数据库服务器。 除非你的网站上有大量的点击，而且你的数据库速度非常快，否则你可能不会注意到很大的不同。
我可以从早期的ASP.NET MVC开发中find唯一的具体数字就是在这个论坛上：
http://forums.asp.net/p/1231621/2224136.aspx
Rob Connery本人有些确认ScottGu声称ASP.NET MVC每秒可以处理8000个请求。
也许杰夫和他的工作人员可以从他们的这个网站的发展中提供一些暗示。
与公认的观点相反，优化的webforms使用完全杀死了原始性能方面的MVC。 Webforms已经超过了MVC的服务时间，
指标可在http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=db上find
每一个比较mvc在列表的中下/上排名，而优化的webforms使用位于上/中上/下排名。
对于这些指标来说，非常严肃的validation， http://www.microsoft.com是由webforms而不是MVC提供的。; 这里有没有人相信，如果它在经验上更快，他们不会selectMVC？
真的没有办法回答这个问题。 MVC默认使用Web窗体视图引擎，并且可以configuration为使用任意数量的自定义视图引擎，所以如果您想要进行性能比较，您必须更加具体。
大约一年前，我开始在MVC工作，我受到了启发，但并没有留下深刻的印象。
我讨厌视图状态，并把它看作是ASP.NET所有邪恶的根源。 这就是为什么我只是不使用它，是完全诚实的，你为什么？
我基本上采用了ASP.NET MVC框架的概念，并以我自己的方式构build。 我改变了一些事情。 我围绕dynamic重新编译构build了我的控制器包装代码或URL路由代码。
现在，我会尽可能地说ASP.NET MVC应用程序将根据您的使用方式更快。 如果你完全放弃了WebForms，那么你将会更快，因为ASP.NET生命周期和对象模型是巨大的。
当你写作的时候，你正在实例化一支军队……不用等待，参与渲染你的视野的一大群物体。 这比在ASPX页面expression最小行为的地方要慢一些。 （我不关心视图引擎抽象，因为在Visual Studio中对ASPX页面的支持是不错的，但是我已经完全放弃了WebForms作为一个概念，基本上任何ASP.NET框架，由于代码膨胀或不能够改变连线我的应用程序的东西）。
我已经find依靠dynamic重新编译（System.Reflection.Emit）的方法，以便在需要时发射特殊用途的对象和代码。 这个代码的执行速度比reflection快，但最初是通过reflection服务构build的。 这给了我的MVC风格的框架很好的performance，但也非常静态types。 我不使用string和名称/值对集合。 相反，我的自定义编译器服务将重写一个表单发布到一个控制器操作被传递一个引用types。 幕后有很多事情要做，但是这个代码很快，比WebForms或者MVC框架快得多。
另外，我不写url，我编写的lambdaexpression式被转换成URL，后来告诉哪个控制器要调用的动作。 这不是特别快，但它打破了url。 这就像是你有静态types的资源以及静态types的对象。 静态types的Web应用程序？ 那就是我想要的！
我会鼓励更多的人来尝试这个。
用Visual Studio创build的项目。 一个是mvc4模板，另一个是WebForm（tranditional）。 而当用WCAT进行负载testing时，这是结果，
MVC4比WebForms相当慢，有什么想法？
MVC4
- 可能会达到11 rps
- rps是非常低的2-CPU或4-CPU服务器
WebForms（aspx）
-
可以达到2500 rps以上
-
性能杀手已被发现是MVC Bata或RC的一个bug。 一旦我删除Bundle的东西，性能会有所提高。 现在最新版本解决了这个问题。
性能取决于你在做什么…通常MVC比asp.net更快，主要是因为Viewstate不存在，因为默认情况下，MVC的工作方式比Callback更多。
如果你优化你的webform页面，你可以获得与MVC相同的性能，但这将是一个很大的工作。
此外，他们是MVC（也为Webform）的许多nugets，以帮助您提高网站的性能，如组合和缩小您的CSS和JavaScript，分组您的图像，并使用它们作为精灵，等等。
网站的性能很大程度上取决于您的架构。 一个干净的，关心好的分离将带给你一个更干净的代码和一个更好的想法如何提高性能。
您可以看看这个模板“ Neos-SDI MVC模板 ”，它将为您创build一个干净的架构，默认情况下有很多性能改进（请查看MvcTemplate网站）。
这是很久以前的一些数字
我用一些基本代码做了一个小的VSTS负载testing实验，发现ASP.NET MVC响应时间比ASP.NET Webforms快两倍。 以上是附图的附图。
你可以阅读这个负载testing实验细节从这篇CP文章http://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari
使用VSTS和telerik负载testing软件，使用以下规格进行testing： –
用户加载25个用户。
运行时间为10分钟。
机器configurationDELL 8 GB RAM，Core i3
项目在IIS 8中托pipe。
项目是使用MVC 5创build的。
networkingLAN连接被假定。 所以这个testing目前没有考虑到networking滞后。
浏览器在testing中select了Chrome和Internet Explorer。
在testing过程中多次读取平均未知事件。 在这里读取7个读数和所有读数作为读数1，2等等。
