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.
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
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.)
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.
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
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.
Related
I know that in PHP we may have multiple (+300) deploys in website without loosing requests on website.
Can we have the same number in ASP.NET MVC? for updating website features and sections?
The deployment usually does is to just replace the whole file folder of the application. So this will create some request issue when copying the files.
The most reliable you are looking for should be a load-balanced environment, where you take down one server and deploy it then make it online, and take care of the other server as well.
IIS has to start the application again after I rebuild the website, it takes a very long time and it cuts into productivity.
I am wondering if I can somehow replace the MVC website with a small console application that listens to a port and returns a string that is then interpreted by the browser as valid html. I am not sure if this was done.
Something very lightweight.
So that it does not take 30-50 seconds on each rebuild, to see my site in action.
I want to build my app, then immediately do a request and test it and not wait almost a minute.
Is there something that does that?
There is a way to build Self-Hosted Web Api applications.
It can be console exe, or setup to run as a service.
The ASPNET engine, is designed to compile itself (views, etc), but a minute? This might be due to the weak PC, for instance.
You can use the Browser control in a windows form app. But it is not recommended, there is no way of avoiding IIS restart since your files have been changed.
I have a Azure website consisting of a WCF endpoint and a MVC website running on Azure. It runs on a basic medium/large tier - so no cap in CPU as Free or Basic has. This has been running perfectly for 6 months probably, with regular deployments and updates. And performance has as expected kept consistent. But now suddenly it takes forever to load the MVC website.
The flow is as follows; we receive a call via the WCF endpoint and then we direct people to a URL that is the MVC web site. All resides on same "web site" inside Azure.
The strange thing is that I can see no difference in my log files. The WCF endpoint responds as quickly as always and from what I can see the heavy lifting inside the MVC also responds as expected, but still the user is left waiting forever on the specified URL?
As said I can't see anything in the performance logs for the MVC controllers, so somehow it seems to be the https request itself that takes ages, but how do I debug or measure this?
I am in the process of getting Visual Studio 2015 to see the remote profiling that can be generated through KUDO - but somehow I don't think that the problems resides here. I am kind of blanking so any thoughts on what could be wrong and how to debug would be appreciated. Also if anyone knows that Azure has released something within the last couple of weeks that might have slowed the application down.
Any chance that you have Application Insights turned on for the MVC site? It has a feature that will track dependency calls and should be able to give you a good idea of what is taking a long time.
https://azure.microsoft.com/en-us/documentation/articles/app-insights-asp-net-dependencies/
I am attempting to do some domain redirects on one of the sites on my server (Server 2003, IIS6), but the Extensionless URLs feature of .Net 4 keeps tacking on that eurl.axd/GUID before the redirect. I found some info on that here.
I would just disable this feature, as described here, but I am pretty sure this will impact an MVC .Net site I also have set up in IIS (because MVC uses extensionless URLs).
Can someone please assist me in finding other options? Is there a way to just remove the eurl.axd/GUID from the URL, via an IHttpModule? I haven't been able to find an example of anyone doing this or something similar.
Ok, I seem to have fixed things on my own. Originally I had both my websites set up in IIS under the same App Pool. I separated them into different app pools, made sure they were both set to .Net 4, and everything started working. Now when users are redirected from one domain to another, the eurl.axd/GUID does not get tacked on to the end of the URL.
As a dev team, we're looking to switch to asp.net MVC and I've heard rumors about IIS 6 not being able to support all of the MVC functionality. Is this true? Is there any official set of functionality supported in IIS 7 vs IIS 6? Should we completely avoid running it on IIS6?
You do not loose any functionality of ASP.Net MVC; however, you have one of two options. You can either define an extension on your URL's which will allow you to set up mapping. So for example:
www.example.com/books/computer/list
might become:
www.example.com/books.mvc/computer/list
You can use any extension you want so long as you map to ASP.Net. I am currently using .aspx which meant I could avoid changing IIS configuration at the sacrifice of having extensionless URLs.
The other option as mentioned is using a wild card mapping. What this does is route all requests to ASP.Net. Even requests for static content such as images. This does have a negative effect on performance that you will want to measure. There are ways around this, I believe such as placing all your content in a specific virtual directory that you turn off the wild card mapping for, but I haven't fully explored that option.
I think the issue with IIS6 is extensionless URLs that you can easily achieve by adding a wildcard ISAPI map in IIS configuration.
So, no. While I love IIS7 integrated mode and strongly recommend using it, you won't lose functionality using it. I've deployed several ASP.NET MVC 1.0 projects on Windows Server 2003/IIS6.
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