I have an asp.net web api application should I use Self Hosting or should I host it on IIS. I am looking for better performance and security. Which one should I be using?
I just show the answer from here.
What I've found (basically just pros for IIS hosted):
You lose all of the features of IIS (logging, application pool scaling, >throttling/config of your site, etc.)...
You have to build every single feature that you want yourself HttpContext?
You lose that since ASP.NET provides that for you. So, I could see that making things like authentication much harder WebDeploy?
IIS has some nice specific features in 8 about handling requests and warming up the service (self-hosted does not)
IIS has the ability to run multiple concurrent sites with applications and virtual directories to advanced topics like load balancing and remote deployments.
And this
Self-hosting is good when you're not on a server -- for example, you want a desktop app to be able to listen for API requests.
But I think you would be able to achive am faster performing and more stable server if it is worth your time. But you need to be carefull not to make basic security mistakes like public accessable configuration files or ddos.
Related
I'm brand new to C#/.NET
Why does ASP.NET have so many different choices of projcets? (Web Application, Web API, Web Site, MVC ect). I just want to listen on a tcp port, and a way to send a response. If there are libraries to help me do routine stuff like constructing the HTTP request, parsing the header, ect - then cool. But I don't want a super opinionated framework that tries to do everything under the sun.
Why do I need IIS at all?
Addressing your points in reverse order, first - why do I need IIS?
The answer is, maybe you don't. If you are doing a simple listener that won't be exposed to the public internet, then you don't need it.
If you are doing a web application that needs to scale, be robust and easy to manage then it can help you with:
Logging
Operating in a multi-server environment for scale/high availability
Handling multiple requests in an isolated way
Serving multiple applications from the same host with sandboxing to ensure each application has guaranteed resources (memory, CPU)
Application lifecycle management
IP address restrictions
support for FTP, CGI, WebDAV
URL rewriting
Response header manipulation
Failed request tracing
Protection against some DoS exploits like slow HTTP attacks
Etc.
In short, it is an industrial strength, real world web server that will keep your application up reliably in a hostile world and scale as your application grows. it is certainly overkill for some cases if you don't need this kind of scale/high availability/management capability. In those cases you have the option to self host ASP.Net in a Windows Service or even a console app. This might sound complicated, but it has been made pretty simple by OWIN - Open Web Interface for .Net. This is an abstraction of the interface used by Asp.Net to communicate with its hosting server.
There is a very good tutorial on how to self host web API in a console app here
http://www.asp.net/web-api/overview/hosting-aspnet-web-api/use-owin-to-self-host-web-api
It does exactly what you ask for in your comment:
You create a console app project
You add references to the right assemblies (the tutorial uses NuGet to download the assembly packages)
You code up your web operation logic
You compile
You run the resulting exe
That's it!
On your second point about ASP.Net - it is a framework that has gone through a lot of evolution trying to keep up with very rapid changes in the web development world. This meant it got a bit bloated and lost some of its coherence, but recently the developers have been focussed on making it more lightweight, more modular and simpler. Scott Guthrie summarises it in his blog:
http://weblogs.asp.net/scottgu/introducing-asp-net-5
Why does ASP.NET have so many different choices of projcets? (Web Application, Web API, Web Site, MVC ect). I just want to listen on a tcp port, and a way to send a response. etc...
Because each project has its own purpose.
If you want to just listen on a TCP port then you could go learn Microsoft's Katana OWIN (but I highly doubt if this is what you want).
Katana OWIN
Briefly going through each projects purpose:
"Web Application" actually opens up another window and lets you choose from the following:
Web API is for exposing RESTful services or JSON data.
Web Forms is for making web pages that use Web Form components.
(A bit like Windows Forms, but Web)
MVC is for making Model-View-Controller web applications. This is where you build components with a separation of concerns. Model for data. View for what the user sees. Controller for controlling how your page behaves.
Why do I need IIS at all?
IIS is for serving .NET applications.
Without it, it would be quite hard to serve .NET applications.
I'll start with 2 then move on to your first question. IIS will run whatever the .NET web service you need, be it a monstrous WCF service, an ASP.NET application or the most basic http handler.
To my knowledge, ISS is the most straightforward way to use .NET web services. If you are used to PHP, it's basically LAMP or WAMP for .NET, which means it is sort of necessary. There are alternatives, as Mike Goodwin points out, but I have to admit I am not familiar with those third parties. Since replacing a layer for another doesnt mean much, I would stick to the "normal" procedure.
Since you dont want the framework to do a truckload of operations for you, your best bet might be along those lines:
Create a basic ASP.NET projet
Remove the default ASP.Net page because it seems you dont want it
Add a Generic Handler to your project. This will result in a myFile.ashx, which handles http requests and let you build any response you want
Of course, if you dont want to bother with IIS configurations, you'll need someone to setup an URL on IIS and map it against your handler repository.
EDIT:
"Abstraction layers" would be the very definition of frameworks, for good or ill, so you're stucked with it.
Now, since you have a low level background a not-so-intrusive way to work with the .NET web services would probably be the three steps I suggested earlier. You are still stucked with IIS though, in order handles the communications (i.e. manages sockets/requests). That's the way the framework works.
STILL, THERE IS HOPE. If you have complete control over your server (which is not my case, some other IT team manages the web servers), you certainly could build a windows service that listens to some socket and work the requests accordingly. It is a most unusal solution if you want to serve web pages, but would work rather well if you only want to push some data through http requests. If you go down this path, I suggest you take a look at the System.Net namespaces, you'll find some classes like "Socket" there. Combined with a console application or a windows service, you could work something out.
One of my coworkers is former microcontroller designer, I know exactly what kind of feeling you have towards the .NET framework. You'll go through some frustrations at times, but most of the time there are work arrounds. Feel free to request more details if you need some.
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.
ASP.NET WebAPI's can either hosted within IIS (as a web role) or be self hosted (as a worker role)
var server = new HttpSelfHostServer(config);
server.OpenAsync().Wait();
The above reminded me of Node.JS. Anyway, I'm trying to list out all the technical tradeoffs between these two approaches. I'm not looking for an opinion on what tradeoffs you prefer - just what those tradeoffs are from a technical perspective. Right now I'm seeing about 8% faster response times per API call in self-hosted mode on our real-world API calls (=Azure SQL + heavy duty number crunching behind the API call). However, I'm concerned that jettisoning IIS will come back to bite us later in the future.
So, what are some major tradeoffs or features lost when avoiding IIS when going the WebAPI self-hosting route?
You lose all of the features of IIS (logging, application pool scaling, throttling/config of your site)....you have to build every single feature that you want yourself
HttpContext? You lose that since ASP.NET provides that for you. So, I could see that making things like authentication much harder
WebDeploy? You would lose that
IIS has some nice specific features in IIS 8 about handling requests and warming up the service
It depends on your application really. You would have to re-write each of those features you need. Node.js provides modules that do that stuff (Express) that the Nginx sever does not have...other than the (event loop async architecture) that is why it is faster.
I know this is not part of your question, but you mentioned a 8% perf gain...that gain is because you don't have the IIS pipeline involved. As you write your own code to mimic IIS functionality you lose, you will ultimitely lose out on that performance
Have you tried Windows 2008 R2/IIS 8? That includes a "free" performance gain over IIS 7.x:
http://blog.bitdiff.com/2012/06/performance-comparison-iis-75-and-iis-8.html
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.
I have a partly developed asp.net application, but now the client wants it to be developed in azure. How much of the existing code can be used in developing the application in azure.
What challenges could we possibly encounter when we try to port an existing asp.net application to azure? Are there any other alternatives to azure in cloud computing?
For an asp.net application, you can certainly port that to Azure. Your core logic will port in a relatively straightforward manner, and you'll gain the many benefits Azure has to offer. With the June 2010 release, you'll also have .NET 4 support, along with IntelliTrace for debugging.
However, as you begin to plan your Azure migration, there are several considerations you'll need to think about (none of them insurmountable, and several relatively simple to deal with):
You have to deal with ASP.NET Session State management across your web role instances (which isn't supported out of the box, except for inproc). You'll also have to set up and use the role and membership providers (see here for more detail). EDIT: You now have access to both AppFabric Cache for session state as well as SQL Azure, part of the Universal Providers included with the Windows Azure SDK+Tools.
You have to examine your SQL backend for incompatibilities with SQL Azure (such as scheduled jobs,since there's no SQL Agent support). SQL Azure differences are documented here. You'll also need to consider the SQL Azure size limit of 50GB, which might require you to offload content to Azure blob storage. EDIT: You can run your SQL Server database through the SQL Azure Migration Wizard for compatibility-testing.
You need to configure logging and diagnostics, preferably with Trace output, so that you can retrieve this data remotely.
You need to think about how you'll monitor and scale your application. All information you might need for scaling is available to you (performance counters, queue lengths, etc.). Check out WASABI - the auto-scale application block, part of Enterprise Library. You can also subscribe to a service such as AzureWatch.
You'll need to think about caching, as there's currently no out-of-the-box caching implementation that runs across instances of your web role which is now provided as a service. Read details here, as well as an FAQ here.
Do you need SMTP support? If so, there are details you should read about here. SendGrid recently announced a free-tier promotion for Windows Azure.
Are you hosting WCF services as well? If so, check out this site for further details (specifically the Known Issues).
So: yes, there are some things you need to concern yourself with, but Azure is a great platform for hosting an asp.net application and you should strongly consider it.
It should be very easy to port your application to Azure--especially if you're using a SQL back-end. The code could run almost without modification. You'll need to create an Azure installation package for the project and configuration file.
If your application makes use of persistent storage (other than SQL Server), you may have to rework that code somewhat. However, the platform now has drive storage, which simulates a file system, so this should be fairly easy.
Another issue to watch out for is web.config. If you make heavy use of this for runtime customization, you'll have to rework that too. You can't deploy single files to your application in Azure, so the recommended approach is to migrate these sort of settings to the Azure config file.
The hardest thing you're likely to encounter is external applications. If your app relies on launching other processes, then this will require some serious redesign.
Azure now supports Web Sites as a deployment type. Basically this allows you to publish any standard Asp.net (and other supported like PHP etc) application to Azure and have it as a scalable server. See this article http://blog.ntotten.com/2012/06/07/10-things-about-windows-azure-web-sites/
Many of the benefits of Azure without having to introduce Azure specific code/Project to your existing application.
Also this question here What is the difference between an Azure Web Site and an Azure Web Role