blocks|key|1558352|text|我能找到的唯一来自早期ASP.NET+MVC开发的具体数字在这个论坛上-线程：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1558353|http://forums.asp.net/p/1231621/2224136.aspx|offset|length|1558354|Rob+Connery本人在某种程度上证实了ScottGu声称ASP.NET+MVC每秒可以处理8000个请求的说法。|1558355|也许Jeff和他的团队可以从他们对这个网站的开发中给出一些提示。|1558356|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|18|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@$D|S|E|T|1|U]]|A|$]]|$1|F|3|G|5|6|7|V|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|W|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|C]]]]

The only concrete numbers I can find which are from early ASP.NET MVC-development is on this forum-thread:

<a href="http://forums.asp.net/p/1231621/2224136.aspx" rel="nofollow noreferrer">http://forums.asp.net/p/1231621/2224136.aspx</a>

Rob Connery himself somewhat confirms statement that ScottGu has claimed that ASP.NET MVC can serve 8000 requests per second.

Maybe Jeff and his crew can give some kind of hint from their development of this site.

blocks|key|1558419|text|我们还没有执行得出任何结论所需的可扩展性和性能测试。我认为ScottGu可能一直在讨论潜在的性能目标。随着我们迈向Beta和RTM，我们将在内部进行更多的性能测试。然而，我不确定我们发布性能测试结果的政策是什么。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1558420|在任何情况下，任何这样的测试都需要考虑现实世界的应用程序...|1558421|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

We haven't performed the type of scalability and perf tests necessary to come up with any conclusions. I think ScottGu may have been discussing potential perf targets. As we move towards Beta and RTM, we will internally be doing more perf testing. However, I'm not sure what our policy is on publishing results of perf tests.

In any case, any such tests really need to consider real world applications...

blocks|key|1773728|text|它将我的一个页面的有效负载从2MB减少到200k，这仅仅是通过消除视图状态并使其在编程上可以处理提交的输出而实现的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1773729|仅仅是大小，即使处理是相同的，也会在每秒连接数和请求速度方面产生巨大的改进。|1773730|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

It decreased one of my pages from 2MB payload, to 200k, just by eliminating the viewstate and making it bearable programatically to work with the submitted output.

The size alone, even though the processing was the same will create vast improvements in connections per second and speed of the requests.

blocks|key|1773800|text|真的没有办法回答这个问题。默认情况下，MVC本身使用Web窗体视图引擎，并且可以配置为使用任意数量的自定义视图引擎，因此，如果您想要进行性能比较，则必须更加具体。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1773801|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

There's really no way to answer this. MVC uses the Web Forms view engine by default itself, and can be configured to use any number of custom view engines, so if you want a performance comparison you'll have to be more specific.

blocks|key|1773853|text|我的测试显示MVC上的req/sec要高出2到7倍，但这取决于你如何构建你的webforms应用。在没有任何服务器端控制的情况下，只有"hello+world“文本，mvc大约快了30-50%25。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1773854|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

My testing shows something between 2x and 7x more req/sec on MVC, but it depends how you build your webforms app. With just "hello world" text on it, without any server side control, mvc is around 30-50% faster.

blocks|key|1558728|text|对我来说，MVC真正的“性能”改进是增加了应用程序的可测试面。对于WebForms，有很多应用程序很难测试。使用MVC，变得可测试的代码量基本上翻了一番。基本上，所有不易测试的都是生成布局的代码。您的所有业务逻辑和数据访问逻辑--包括填充视图中使用的实际数据的逻辑--现在都可以进行测试了。虽然我希望它的性能也会更好--页面生命周期大大简化，更容易接受web编程--但从质量的角度来看，即使它是一样的或稍微慢一点，也是值得改用的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1558729|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

For me the real "performance" improvement in MVC is the increase the testable surface of the application. With WebForms there was a lot of the application that was hard to test. With MVC the amount of code that becomes testable basically doubles. Basically all that isn't easily testable is the code that generates the layout. All of your business logic and data access logic -- including the logic that populates the actual data used in the view -- is now amenable to testing. While I expect it to be more performant as well -- the page life cycle is greatly simplified and more more amenable to web programming -- even if it were the same or a little slower it would be worth switching to from a quality perspective.

blocks|key|1558774|text|我认为，许多认为WebForms天生就很慢或资源密集型的人把责任推到了错误的地方。当我被带去优化一个webforms应用程序时，10次中有9次有太多的地方应用程序作者误解了视图状态的目的。我并不是说viewstate是完美的，但它太容易滥用了，正是这种滥用导致了viewstate字段的膨胀。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1558775|这篇文章非常有价值，它帮助我理解了其中的许多弊端。https://weblogs.asp.net/infinitiesloop/truly-understanding-viewstate|offset|length|1558776|为了在MVC和WebForms之间进行有效的比较，我们需要确保这两个应用程序都正确地使用了架构。|1558777|entityMap|0|LINK|mutability|MUTABLE|url|https://weblogs.asp.net/infinitiesloop/truly-understanding-viewstate^0|0|P|1W|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

I think that many of the people who think that WebForms are inherently slow or resource intensive are placing the blame in the wrong place. 9 times out of 10 when I am brought in to optimize a webforms app there are way too many places where the apps authors misunderstand the purpose of the viewstate. I'm not saying that the viewstate is perfect or anything, but it is WAY too easy to abuse it, and it is this abuse that is causing the bloated viewstate field.

This article was invalueable in helping me understand many of these abuses. <a href="https://weblogs.asp.net/infinitiesloop/truly-understanding-viewstate" rel="nofollow noreferrer">https://weblogs.asp.net/infinitiesloop/truly-understanding-viewstate</a>

In order to make a valid comparison between MVC and WebForms we need to be sure that both apps are using the architectures correctly.

blocks|key|1774076|text|大约一年前，我开始在MVC工作，我受到了启发，但没有留下深刻的印象。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1774077|我讨厌视图状态，并将其视为ASP.NET中所有邪恶的根源，这就是为什么我不使用它，老实说，你为什么要使用它呢？|1774078|我基本上采用了ASP.NET+MVC框架的概念，并以我自己的方式构建它。不过，我改变了一些事情。我构建了我的控制器包装代码，或围绕动态重新编译的URL路由代码。|1774079|现在，我甚至可以说，根据您的使用方式，ASP.NET+MVC应用程序将会更快。如果完全放弃WebForms，速度会更快，因为ASP.NET生命周期和对象模型非常庞大。|1774080|当你在写的时候，你正在实例化一支军队...不，等等，大量的对象将参与你的视图的渲染。这将比在ASPX页面本身中表达最小数量的行为要慢。(我不关心视图引擎抽象，因为Visual+Studio中对ASPX页面的支持还不错，但由于代码膨胀或无法更改连接应用程序的内容，我已经完全放弃了WebForms这一概念，也放弃了基本上所有的ASP.NET框架)。|1774081|我已经找到了依赖动态重新编译(System.Reflection.Emit)的方法，以便在需要时发出特殊用途的对象和代码。此代码的执行速度比反射快，但最初是通过反射服务构建的。这给了我的MVC风格的框架很好的性能，但也是非常静态类型的。我不使用字符串和名称/值对集合。相反，我的自定义编译器服务将表单post重写为传递引用类型的控制器操作。在幕后有很多事情在进行，但这段代码很快，比WebForms或MVC+Framework快得多。|1774082|另外，我不写URL，我写的是lambda表达式，这些表达式被转换成URL，然后这些URL告诉我们要调用哪个控制器操作。这不是特别快，但它比破坏URL要快得多。这就像你有静态类型的资源和静态类型的对象。静态类型的web应用程序？这就是我想要的！|1774083|我会鼓励更多的人尝试一下。|1774084|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|V|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|X|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|Y|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|Q|$]]

I started out work in MVC about a year ago, I was inspired but not impressed.

I loath the view state and see it as the root of all evil in terms of ASP.NET. This is why I just don't use it and to be perfectly honest why would you?

I took basically the ASP.NET MVC Framework concept and built that in my own way. I changed a couple of things though. I built my controller wrapping code, or URL routing code around dynamic recompilation.

Now, I would go as far as to say that ASP.NET MVC applications will be faster based on how you use it. If you completely abandon WebForms you'll be faster becuase the ASP.NET life-cycle and object model is humongous.

When you're writing you're instantiating an army... no wait, a legion of objects that will participate in the rendering of your view. This is gonna be slower than if you where to express the minimal amount of behavior in the ASPX page itself. (I don't care about view engine abstraction because the support for ASPX pages in Visual Studio is decent, but I've completely dropped WebForms as a concept and basically any ASP.NET framework due to code bloat or not being able to change the things that wire my application).

I've found ways of relying on dynamic recompilation (System.Reflection.Emit) for emitting special purpose objects and code whenever needed. The executing of this code is faster than reflection but initially built through the reflection service. This has given my MVC flavored framework great performance but also very statically typed. I don't use strings and name/value pair collections. Instead my custom compiler services goes in a rewrites a form post to a controller action being passed an reference type. Behind the scene there is a lot of things going on but this code is fast, a lot faster than WebForms or the MVC Framework.

Also, I don't write URLs, I write lambda expressions that get translated into URLs that later tell which controller action to invoke. This isn't particularly fast but it beats having broken URLs. It's like if you had statically typed resources as well as statically typed objects. A statically typed web application? That is what I want!

I would encourage more people to try this out.

blocks|key|1774180|text|我认为这里的问题是，无论ASP.Net+MVC比旧的webforms快多少，都不会有什么不同，因为大部分时间都在数据库中。大多数时候，您的web服务器将坐在0-10%25的CPU使用率，只是等待您的数据库服务器。除非你在你的网站上获得了非常多的点击量，而且你的数据库非常快，否则你可能不会注意到很大的区别。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1774181|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I think the problem here is that no matter how much faster ASP.Net MVC is than the old webforms, it won't make a difference, because most of the time taken is in the database. Most of the time, you web servers will be sitting at 0-10% CPU usage just waiting on your database server. Unless you get an extremely large number of hits on your website, and your database is extremely fast, you probably won't notice a big difference.

blocks|key|1559030|text|性能取决于你在做什么……通常，MVC比asp.net更快，主要是因为视图状态不存在，而且在默认情况下，MVC更多地处理回调而不是回发。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1559031|如果你优化你的webform页面，你可以拥有与MVC相同的性能，但这将是大量的工作。|1559032|此外，它们是许多MVC+(以及Webform)的小玩意儿，可以帮助你提高网站性能，比如组合和缩小你的css和javascripts，将你的图像分组并将它们用作精灵，等等。|1559033|网站的性能在很大程度上取决于你的架构。具有良好关注点分离的干净代码将为您带来更干净的代码，并更好地了解如何提高性能。|1559034|你可以看看这个模板"Neos-SDI+MVC+Template“，它将为你创建一个干净的架构，默认情况下会有很多性能改进(请查看MvcTemplate网站)。|offset|length|1559035|entityMap|0|LINK|mutability|MUTABLE|url|http://visualstudiogallery.msdn.microsoft.com/3702cff6-d04e-4aca-bcd8-01d0822de9f7|1|http://www.mvctemplate.com/^0|0|0|0|0|A|L|0|1S|B|1|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@$J|10|K|11|1|12]|$J|13|K|14|1|15]]|A|$]]|$1|L|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|M|$N|$5|O|P|Q|A|$R|S]]|T|$5|O|P|Q|A|$R|U]]]]

Performance depends on what you are doing... Usually MVC is faster than asp.net mostly because Viewstate is absent and because MVC works more with Callback than Postback by default.

If you optimize your webform page you can have the same performance as MVC but it will be a lot of work. 

Also, their is a lot of nugets for MVC (and also for Webform) to help you to improve website performance like combine and minify your css and javascripts, group your images and use them as a sprite, and so on.

Website's performance depend greatly of your architecture. A clean one with good separation of concern will bring you a more clean code and a better idea of how improve performance.

You can take a look at this template "<a href="http://visualstudiogallery.msdn.microsoft.com/3702cff6-d04e-4aca-bcd8-01d0822de9f7" rel="nofollow">Neos-SDI MVC Template</a>" which will create for you a clean architecture with lots of performance improvements by default (check <a href="http://www.MvcTemplate.com" rel="nofollow">MvcTemplate</a> website).

blocks|key|1774300|text|与公认的观点相反，优化的webforms使用在原始性能方面完全扼杀了MVC。Webforms已经为处理html的任务进行了超优化，时间比MVC要长得多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1774301|指标可在http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=db上找到|offset|length|1774302|每一次比较mvc都在列表的下-中/下-上排名，而优化的webforms使用在上-中/上-下排名。|1774303|www.microsoft.com是由webforms而不是MVC提供服务的，对这些指标的验证是传闻但非常严肃的。这里有没有人相信，如果MVC在经验上更快，他们就不会选择MVC？|1774304|entityMap|0|LINK|mutability|MUTABLE|url|http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=db|1|http://www.microsoft.com/^0|0|4|1W|0|0|0|0|H|1|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@$D|V|E|W|1|X]]|A|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@$D|10|E|11|1|12]]|A|$]]|$1|J|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]|R|$5|M|N|O|A|$P|S]]]]

Contrary to the accepted opinion, optimized webforms usage completely kills MVC in terms of raw performance. Webforms has been hyper-optimized for the task of serving html far longer than MVC has.

Metrics are available on <a href="http://www.techempower.com/benchmarks/#section=data-r7&amp;hw=i7&amp;test=db" rel="nofollow">http://www.techempower.com/benchmarks/#section=data-r7&amp;hw=i7&amp;test=db</a>

Every single comparison mvc is on the lower-middle/lower-upper rankings of the list, while optimized webforms usage places in the upper-middle/upper-lower rankings.

Anecdotal but very serious validation to these metrics, <a href="http://www.microsoft.com" rel="nofollow">www.microsoft.com</a> is served by webforms not MVC. Does anyone here believe that they wouldn't have chosen MVC if it was empirically faster?

blocks|key|1774400|text|​|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1774401|📷|atomic|offset|length|1774402|1774403|我用一些基本代码做了一个小型的VSTS负载测试实验，发现与ASP.NET+Webforms相比，ASP.NET+MVC的响应时间快了一倍。上图是附图。|1774404|您可以从这篇CP文章https://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari中详细阅读这个负载测试实验|1774405|使用VSTS和telerik负载测试软件使用以下规格进行测试：|1774406|用户负载25个用户。|1774407|测试运行时间为10分钟。|1774408|机器配置戴尔8+GB+Ram，核心i3|1774409|项目驻留在IIS+8中。|1774410|项目是使用MVC+5创建的。|1774411|假定有网络LAN连接。因此，此测试暂时不会考虑网络延迟。|1774412|测试中的浏览器选择了Chrome和Internet+explorer。|1774413|在测试期间获取多次读数，以求未知事件的平均值。7阅读内容，所有阅读内容在本文中都作为阅读1、2等发布。|1774414|entityMap|0|IMAGE|mutability|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/3f089d8fafe8b6e751f022c57bd35e52.png|imageAlt|1|LINK|MUTABLE|url|https://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari^0|0|0|1|0|0|0|0|A|2M|1|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|1I|8|@]|9|@$E|1J|F|1K|1|1L]]|A|$]]|$1|G|3|4|5|6|7|1M|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1N|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1O|8|@]|9|@$E|1P|F|1Q|1|1R]]|A|$]]|$1|L|3|M|5|6|7|1S|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1T|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1U|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1V|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1W|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1X|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|20|8|@]|9|@]|A|$]]|$1|13|3|-4|5|6|7|21|8|@]|9|@]|A|$]]]|14|$15|$5|16|17|18|A|$19|1A|1B|-4]]|1C|$5|1D|17|1E|A|$1F|1G]]]]

<img src="https://i.stack.imgur.com/I7eXy.png" alt="enter image description here">

I did a small VSTS load test experiment with some basic code and found ASP.NET MVC response time to be twice faster as compared to ASP.NET Webforms. Above is the attached graph with the plot. 

You can read this load test experiment in details from this CP article <a href="https://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari" rel="nofollow noreferrer">https://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari</a>

Test was conducted with the below specifications using VSTS and telerik load test software:-

User load 25 users.

Run duration of test was 10 minutes.

Machine config DELL 8 GB Ram, Core i3

Project was hosted in IIS 8.

Project was created using MVC 5.

Network LAN connection was assumed. So this test does not account for network lag for now.

Browser in the test selected Chrome and Internet explorer.

Multiple reading where taken during the test to average unknown events. 7 readings where taken and all readings are published in this article as reading 1 , 2 and so on.

I found some wild remarks that ASP.NET MVC is 30x faster than ASP.NET WebForms. What real performance difference is there, has this been measured and what are the performance benefits.

This is to help me consider moving from ASP.NET WebForms to ASP.NET MVC.

ASP.NET MVC Performance

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我发现一些关于ASP.NET MVC比ASP.NET WebForms快30倍的胡言乱语。真正的性能差异是什么，是否测量过这一点，以及性能优势是什么。这是为了帮助我考虑从ASP.NET WebForms迁移到ASP.NET MVC。

问ASP.NET MVC性能
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问ASP.NET MVC性能EN