Now that the final version of MVC 3 has been released I think information about the performance characteristics of this latest installment would be very useful for those weighing the pros and cons of updating their MVC 2 applications. In this post I will talk about what you might expect when moving to MVC 3. The short answer is things should be about the same.
Of course that short statement is not accurate because the only correct answer to such performance questions is: “it depends”. It depends on what your application does and which features it is using: database connections, business logic, output caching, html helpers, etc. I say this because in a moment I will present some numbers and they might not correspond to what you would see in your application. But they should provide you with a good starting point.
The more detailed answer is that some applications will perform better while others will perform worse. That is because as we added new features (dependency injection, improved filters, etc.) some components of MVC 3 got slower than in MVC 2 simply because they are now doing more work. At the same time we have introduced targeted performance optimizations which improved other components. The only definite way you can know the impact on your application is if you carefully measure performance yourself. At the end of this post I will provide a rough list of some of the things that have gotten faster or slower.
The application I will use for the tests is the default “Internet Application” project template that ships with every installation of MVC. While quite small, it is still a pretty good choice because it uses a wide variety of MVC features. This means that the test exercises a large part of the framework without focusing on any individual features.
For my tests I have the following applications:
I modified each of these applications in the following ways to ensure consistency and remove unnecessary noise from the results:
For each of the applications I executed the following sequence of requests and recorded the throughput (number of requests per second). The sequence ran for about 1 hour in our performance testing lab (meaning that the results should be amortized with respect to any other OS tasks that might have occurred on the server).
Note: The above results were captured on a 12-core server and should only be used for comparative purposes. Absolute RPS values on your own machine might de vastly different but their relative distribution should remain the same.
As you can see from comparing the results for Application 1 and Application 2 the difference is quite small. In fact –1.82% falls within the margin of error. Application 1 and Application 2 are the same identical application, except 1. references System.Web.Mvc.dll version 2.0 and 2. references System.Web.Mvc.dll version 3.0. These results are why we say that MVC 3 is on par with the performance characteristics of MVC 2.
Of course followers of Scott Guthrie will point out that with the RC2 release he claimed that MVC 3 was faster than MVC 2. While that was true at the time it is not correct any longer for RTM. We had to undo a pretty significant performance fix related to model metadata caching because it caused some functional bugs (after all it does not matter how fast your application is if it does not actually work correctly). However, we will have that improvement available as an add-on in MVC Futures and we will roll it into MVC 4.
The comparison of Application 3 and Application 4 will be of interest to those looking at adopting the new Razor view engine. Application 4 is –4.3% slower than Application 3. This shows that using Razor does have a performance cost. However, that difference is not that big and is outweighed by the elegance and increased readability of the new view engine. Razor is also a new technology and I am sure that as it matures we will be able to optimize it even further.
At the beginning of this post I promised that I would list how the various features or components of MVC changed in their performance characteristics. This list is compiled from our internal performance tests as well as change logs. It is meant to be taken as informational only. Your results may vary and depends on how you actually use each feature and what else you have happening in your application
Things that got faster (in no particular order):
Things that got slower (also in no particular order):
Of course I am not going to tell you by how much things have changed because it depends... you will have to measure yourself.
Nice work. However, I expect next post on "how to improve performance server side with MVC3" - maybe with David Ebbo template transforming aspx to code?
Andrei, do you mean precompiled views? Cause that wouldn't affect performance except for the startup time of the application.
Please write more about your test setup: was test client and server on same machine, LAN, how many concurrent users or parallel requests, IIS and server OS versions ...
8000 RPS is quite high, it looks like kernel caching on IIS or something like that. I was able to get around 700 RPS, but not on that powerful machine ...
hrvoje, these tests were performed on a 12-core 16GB of RAM x64 2008 Enterprise server. Requests are coming from seperate machines (300 virtual parallel clients total), and everything is on a private network. IIS is configured with default values.
At some point in the future I'll blog more about general testing methodologies for MVC.
that's great, thanx for info!
It would be interesting to compare this with regular asp.net webforms app! And while you have all that machines in place, maybe test clean installation of some OSS .net products: Dontnetnuke, Orchard, N2CMS, ... :) ?
It would be quite difficult to construct valid (apples-to-apples) comparison of all of these applications because they don't always do the same thing (because it highly depends on the scenarios that you are targetting). Ultimately, it's up to the various application developers to ensure they perform as best as possible.
as far as i understand - mvc 2 work slowly than mvc 3?
Because mvc 2 - 8135 request per second
mvc 3 razor 3 - 7136 ... isn't it?
jj, the number means how many requests the server can handle per second. A higher number means that the server can handle more requests and therefore performs better