views:

721

answers:

5

We are getting ready to do a an initial deployment of an ASP.net MVC app on IIS 6 running on Windows Server 2003. We've been reading about performance issues involving the use of extenionless urls in MVC applications specifically in the case of removing the '.aspx' extension from the controller portion of the url.

Has anyone who has deployed an MVC app in the past experienced any performance degradation in this area? Was it noticeable, and was it worth it for having the cleaner URLs? Our application will rarely have to deal with more than 1000 or so concurrent users.

Edit: Thanks for all the responses, it's working quite well, although there are a few strange requests going through as some people mentioned, I think we can work around these using the suggestions mentioned here.

+2  A: 

The problem with not using extensions on IIS 6 is that you don't want static requests to go through the ASP.NET stack. If all of your static requests come from one (or two...) subfolder(s), you can exclude them. This should fix the performance issue.

Quoting from the linked post:

Now, to remove the wildcard map on the /Content subdirectory, open a command prompt, go to c:\Inetpub\AdminScripts, and run:

adsutil.vbs SET /W3SVC/105364569/root/Content/ScriptMaps ""

… replacing 105364569 with the “identifier” number of your application. (Also, you could replace “Content” with the path to any other directory.)

Craig Stuntz
Also, if you can't find the metabase path to your app, you can do aspnet_regiis -lk. That should list all of the apps for you, displaying their metabase paths.
Samuel Meacham
+1  A: 

Instead of serving all the requests by ASP.NET, you could specify e.g. mvc as the extension (say index.mvc) and map that extension to aspnet_isapi.dll in IIS 6. This means only known extenions will be processed by asp.net, others like static files stay the same as before i.e. served by IIS itself.

codemeit
We do this, and it works quite well. Plus we get to use .ftw as the extension, which always makes us happy.
jasondoucette
+2  A: 

We recently deployed an app that received approx. 20 million page views over a 3 month period using the IIS 6 wildcard mapping setup and had no performance issues. We did host most of our images on a CDN, but other static content was served directly from the site.

For what it's worth, IIRC, the asp.net handler will pass requests for static file types back to IIS through a default handler for processing. The only practical performance hit is the time during that process that a worker thread is occupied identifying and transferring the request. In all but the most extreme scenarios, this is too trivial to matter.

As an extra note, we load tested the application I mentioned prior to going live and found that it could handle nearly 2000 static requests per second and around 700 requests per second for pages that involved database activity. The site was hosted on 4 IIS 6 servers behind a ZXTM load balancer with a 1GB internet pipe.

Here's a link with some good advice on the whole static file handling business:

http://msmvps.com/blogs/omar/archive/2008/06/30/deploy-asp-net-mvc-on-iis-6-solve-404-compression-and-performance-problems.aspx

Chris
Marked yours as the answer because it relates directly to performance which was our main concern, wish we could mark assisted solutions here as well.
Graham
+2  A: 

We ran a fairly busy site with IIS6 wildcards on for extensionless URLs and although we never noticed much of a performance hit, we did have a little hack that worked quite well:

For all folders that contained only static files, like /css, /images, /scripts etc, in IIS we set them as their own application, and disabled the wildcard setting, which meant IIS handled the requests rather than routing through ASP.Net.

JonoW
I use this and it works well.
boomhauer
+2  A: 

Url rewriting can help you to solve the problem. I've implemented solution allowing to deploy MVC application at any IIS version even when virtual hosting is used. http://www.codeproject.com/KB/aspnet/iis-aspnet-url-rewriting.aspx

Alex Ilyin
Thanks Alex, I'll check it out.
Graham