.
Hi,
We have built an ASP.NET application (with C#.net language) and hosted on IIS 6.0 on Windows Server 2003 Operating System.
Now we need to optimize the IIS performance so that the pages get served fast.
Would you please let me know if you have any idea on this?
If would be great if you could provide the relevant doc or web reference (If needed).
Many Thanks,
Regards,
Venkat.
.
its not really a question of tuning the iis, as much as your code.
iis
tune your caching and compression settings
only have one default document
don't use extensionless handlers
these settings are virtually pointless though if the code you have written is not optimized
asp.net
never run in debug mode
be carefull with exceptions since they are expensive
use page and usercontrol caching correctly
set caching, etag and expires headers correctly on your http-response
compress your javascript and stylesheets (there is different 3rd party components for this)
reduce the number of http requests
use sprites for small image icons etc.
links
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/25d2170b-09c0-45fd-8da4-898cf9a7d568.mspx?mfr=true
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/71490aae-f444-443c-8b2a-520c2961408e.mspx?mfr=true
http://en.wikipedia.org/wiki/HTTP_ETag
http://developer.yahoo.com/performance/rules.html
Related
I am exploring the current news for ASP.NET WinForms with .NET 4.6.
The resources I am currently looking at is this Video overview by Microsoft Program Manager Pranav Rastogi and an article on DotNetCurry. Besides the information, that I will require Windows 10 Preview, I can not decipher, what this really means to me as a WebForms developer.
To use HTTP/2 will I...
need to make some changes in a config file?
need to change something in the page / master page?
use a different programming model when it comes to serve resources?
Of course, IIS will need to be configured, but this does not affect me as developer.
Is there actually something I need / can do as developer to support HTTP/2?
Note: If someone sees this as a better fit on Programmers or other SE site, please move.
Basically, HTTP/2 is seemless for web services. The basic functions, request/response multiplexing and header compression, are defined at the network protocol level. That means it can be seen as the matter of web browsers and web servers.
But for the new features like HTTP/2 server push and stream priority/dependency, it needs to be considered for developers. To use those features, web browsers and web servers should provide APIs.
If I understand correctly part of the motivation of ASP.NET vNext is to reduce overhead. An MVC6 application can be self hosting. My question is what is the best practice way of hosting a ASP.NET vNext application. Is there something similar to the WCF activation services that monitor the health of the service or is there some way of doing this from within the application?
The "best" way to host ASP.NET MVC 6 is to choose the way that best matches your app's needs, of course! But that perhaps isn't so helpful as far as advice goes.
First, you need to consider the requirements of the application, such as:
Does it need to run cross-platform?
Does it need health management?
Does it need to use existing IIS modules?
Does it need to run in the context of another application?
Does it need to use Windows Authentication?
And no doubt many more requirements...
Here's a brief summary of the various hosting options and their pros/cons:
IIS is perhaps the most well-known host. It has been hardened for well over a decade. Many popular modules are available for it, including providing various security features. IIS has built-in support for Windows Authentication, logging, app warmup, health management, remote administration, and lots of other features.
IIS Express shares the same codebase as IIS, but can be run without admin privileges.
Kestrel is a cross-platform web server that is being written as part of ASP.NET 5 and is currently most suited for development work. It's very lightweight, which can be both good (nothing in the way!) and bad (not very many features).
Self-host is where you are master of your own domain. Nearly everything is up to you, including figuring out what should happen if there is an unrecoverable error. Self-hosting is a great option if you need to host a server within your app (e.g. a client app that uses a web server to host UI or services that the app directly uses).
There is certainly no one "best" way to host an ASP.NET MVC 6 app, but there are certainly many solutions catered to a variety of needs.
In my answer to ASP.NET vNext is host agnostic, what does it deeply mean? I covered a few other aspects of host agnosticism.
ASP.NET Core 1.1 Answer
The 1.1 release added GZIP compression and response caching.
Kestrel is still not security tested and should not be used without IIS or NGINX as a reverse proxy. This will change at some point.
Kestrel still does not support HTTP 2.0.
Using IIS or NGINX with MVC 6 is slower than MVC 5. Yes MVC 6 is supposed to be faster but only if you use Kestrel on it's own.
ASP.NET Core 1.0 Answer
IIS or NGINX is by far the best host for an ASP.NET MVC 6 application. Below are a list of features you will not get without IIS or NGINX without lots of extra work. Note that all of these features require a small amount of config in the web.config file.
The Kestrel web server has not been battle hardened and tested for security. It's not supposed to be exposed to the internet...yet.
Kestrel does not support HTTP 2.0.
GZIP compression of HTTP requests for saving bandwidth and better performance. This alone is a big enough reason.
Error handling outside of ASP.NET. What happens when you have a .dll file missing? Well IIS will still show an error page and you can customize the error page too.
Dynamic IP security - During a Denial of Service (DoS) attack, a very simple and small 403.501 or 403.502 Forbidden static error page is displayed.
When I run the Google Chrome Page Speed on one of the web sites I created, I got the following warning for lots of static resources (.js, .jpg, .png, .css files);
The following cacheable resources have a short freshness lifetime.
Specify an expiration at least one week in the future for the
following resources:
http://www.example.net/Content/App_Icons/Exported/MC900304631.png
(expiration not specified)
My app is an asp.net and asp.net mvc hybrid app and running on windows server 2008 r2, IIS 7.5.
How can I enable that feature? Couple of moths ago, I heard something about eTag bhut don't if it has anything to do with that. could provide examples or good resources on this?
can you try this?
http://www.iis.net/ConfigReference/system.webServer/staticContent/clientCache
I have a need to run an application in classic mode for backwards compatibility with a specific application, and am trying to understand what kind of impact that will have on the performance of an MVC application that is running on the site.
If we put a few static file maps (for .js, .css, .png, etc) above the ASP.NET wildcard map to reduce the amount of processing by the ASP.NET handler, will we be approaching the integrated mode in terms of performance?
The thing i'm primarily concerned with is any effect this might have on output caching. I understand that integrated mode might (?) allow for the output cache to handle non ASP.NET content, but that isn't really a concern. We're more interested in ensuring that the MVC application has full use of the output cache.
Empirically i've found that the two configurations operate on par when things go well, but if the page references resources that are not available, the integrated mode tends to fail much more quickly than the classic mode (e.g. 500 ms vs 10 seconds), reducing 'hang time' on the page load.
Thanks for any feedback.
The thing is you have told IIS to run a particular application in classic mode. Now sit back and see. I should do it.
I don't think if you are running only one application on classic mode, it should affect another application running on integrated mode.
I have a number of web apps running on several IIS6/Server 2003 boxes. They run well and are happy. They are all asp.net web apps and use .NET 3.5.
What, if any, would be valid reasons for contemplating moving the web apps to IIS7/Server 2008?
IIS7 is rewritten from the ground up with a concept of being "pluggable". IIS7 is more extensible than it ever has been before. The entire request pipeline has be reworked to allow you to more easily work with requests, as well.
From a performance aspect, these changes are immediately recognizable. You can run sites developed for IIS6 in a "Classic" application pool that will preserve compatibility, but provide a noticeable performance boost. In the non-scientific evaluation that we have done so far, our legacy application has seen about a 20% reduction of load times on our IIS7 test machine.
Of course, the reason we have to run in "classic" mode is an interesting side note. Inside the global.asax, there is some pre-fetching on application start which touches the HttpContext. Specifically, there is pre-caching done, which IIS7 does not allow. So, before we can switch from "classic" mode, there are some changes that we will have to make.
Eventually, Microsoft will discontinue Server 2003 support. Admittedly, that won't be for several years, so it doesn't impact you today.
Improved support for ASP.NET MVC. This is probably the big one for most of us. You can get ASP.NET MVC working on IIS6, but there are some hoops to jump through.
I'd give you more, but I myself am not yet on Server 2008 yet, and have nothing else to give. Presumably Vista (which I do use, both at work and at home) has the "same" IIS7 as 2008 does -- the UIs certainly look very similar -- but I wouldn't consider my experience there to be useful to your question.
Ability to write pipeline components in managed langauges. Previously, if you wanted to write an ISAPI filter to handle a certain type of web request, you'd have to write it in C++. Now, you can use good ol' .NET code. This allows more customization with the ability to write reusable pipeline components for handling various types of request. For example, all .js file request are routed to a ScriptCompressor pipeline component which zips and returns them with lots of cacheability set up.
The improved support for MVC is linked to this as you can set II7 to route requests without extensions to .NET so you can have urls which are "cleaner" such as http://www.yourwebsite.com/customer/1 without having any extension visible which reveals what type of server technology you're using and is very untrendy these days.