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.
Related
Is there any way I use a desktop application based on forms on a server through an asp.net web page client side?
I believe that you will be blocked by antivirus/antimalware solutions (even those from Microsoft).
You could start an aplication from browser IF using a kind of Plug-In, but in the last years that is exactly the way of malwares and viruses to damage computers. And because of it, evey security application (and even UAC and browsers themselves) are not allowing that kind of action.
You may risk put your solution into a plug-in and it be confused with viruses/malwares.
I'm trying to eliminate (or at least minimize) startup/warmup times for my .NET applications. I'm not really sure on how to do this even though it's a common concern.
There's a ton of questions about slow startup of .NET applications. These are easily explained by pool recycles, worker process startup, dynamic compilation of .aspx files, JIT etc. In addition, there are more things that may need to be initialized within the application such as EntityFramework and application caches.
I've found alot of different solutions such as:
ASP.NET Precompilation
IIS 8 Application Initialization (and for IIS 7.5)
Auto-Start ASP.NET Applications
However, I'm not entirely satisfied with any of the solutions above. Furthermore I'm deploying my applications to Azure Websites (in most cases) so I have limited access to the IIS.
I know that there are some custom "warmup scripts" that uses various methods for sending requests to the application (e.g. wget/curl). My idea is to create a "Warmup.aspx" page in each of my ASP.NET applications. Then I have a warmup service that sends an HTTP GET to the Warmup.aspx of each site every ... 5 minutes. This service could be a WorkerRole in Azure or a Windows Service in an on-premise installation. Warmup.aspx will will then do the following:
Send an HTTP GET to each .aspx-file within the application (to
dynamically compile the page)
This could be avoided by precompiling the .aspx pages using aspnet_compiler.exe
Send a query to the database to
initialize EntityFramework
Initialize application caches etc
So, my final question is whether there are better alternatives than my "Warmup.aspx" script? And is it a good approach or do you recommend some other method? I would really like some official method that would handle the above criteria.
Any and all suggestions are welcome, thanks!
Did you try this IIS Auto-Start feature described here ?
https://www.simple-talk.com/blogs/2013/03/05/speeding-up-your-application-with-the-iis-auto-start-feature/
You could have two instances of the site. When you need to deploy a new version, and therefore suffer a startup cycle, remove one instance out of load balancer rotation, deploy and start it, set it in and do the same for instance 2. A rolling deployment.
We have a web site built as an 'ASP.NET Website' type project, rather than the 'ASP.NET Web Application' type.
Aside from the obvious debugging advantages that the app type offers and access to the designer files for each page:
What, if anything, can be gained by switching from website project type to app?
Are there performance losses with one over the other?
How much work is involved in switching an existing (dev) site from website to app? Is it as simple as creating another site as app type and adding these existing aspx files and libraries to it?
This question (How To Convert ASP.NET Website to ASP.NET Web Application) seems to cover the steps.
What are the risks (if any?)
How much work should we plan on?
Are there differences in how HTTP Application deals with requests or how handlers work between the two types?
Anything we forgot to think of?
http://msdn.microsoft.com/en-us/library/aa730880%28VS.80%29.aspx#wapp_topic5
That describes some of the features and advantages/disadvantages between the two.
The main reason to use the web project versus the web site is that the web site is dynamically compiled which tends to incur a performance hit whereas the web project is precompiled. You should gain performance moving to the web project method. You also gain control over the naming of your final compiled assemblies.
The amount of work really depends on how many pages are in your old site.
I don't think the .NET framework handles code differently in the web site versus the web project. It's really the configuration of the file structure, the lack of a central project file, and the method of compilation that ends up being different between the two.
.
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
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.