Last post May 21, 2013 11:58 AM by trag1
May 20, 2013 09:51 AM|trag1|LINK
I've found very little in regards to the difference's (pros / cons) of going the Self-hosted route or the standard IIS hosted with a Web Api service. I'm sure others out there feel the same and was hoping a few local experts could share their thoughts on
it to get a good reference on which way to go out here for people to view.
In my case we're going the service route to expand out our reach for mobile type devices, but it still leaves me questioning if there is a right or wrong way to go with this or basically in what scenario would one opt for a "Self-Hosted" service over IIS?
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.
May 20, 2013 10:15 AM|BrockAllen|LINK
Most deployments will be in IIS for the features you cited. 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.
May 20, 2013 12:50 PM|trag1|LINK
Thx for the response Brock
May 20, 2013 05:07 PM|Darrel Miller|LINK
Let me first admit that I am biased towards self-host :-)
IIS logging is useful as long as what you want to log is in the standard set of values. Once you have to go to custom logging it gets way more complicted. Adding W3C style logging using a message handler to self host is pretty easy.
Many of the IIS features like restarting after errors are available to Windows Services.
Self-host can easily run many sites on a single machine, on a single port. You can even create one main site and a backup one at the same address that will kick in only if the main site does not respond.
If you ever want to see why I choose to use self-hosting, just turn on Failed Request Tracing and look at the log to see all the things that happen in the IIS/ASP.NET request pipeline. Self-host is a massively simpler model.
Self-host sites are far more insulated from other applications installed on a server. When deploying an application to IIS, it is failrly easy for the installation of some other site, or just configuring IIS to break your site.
It is true that currently there are far more "out of the box" features available for IIS. However, as the Owin community develops sharable intermediary components, many of the pieces of functionailty that IIS provides will be available to plug into self-host
A self-host server can sit behind a load balancer in exactly the same way that an IIS site can. Currently there is not much of a remote deployment story for windows services. However, using MSIs makes deploying services fairly easy. Also, with libraries
like TopShelf you can make xCopy deployments without any problem.
I think if you a building a very large web site with multiple application servers and using a large percentage of the IIS features then maybe the complexity of IIS is worth it, but for me it's just a huge amount of overkill to be able to handle HTTP requests.
May 21, 2013 10:05 AM|trag1|LINK
Thanks for your insight and thoughts on this. Your making the decision a lot harder now - thanks a lot! ;)
From your comments one stood out to me in that if the pipeline is conjested using iis and not with self-hosting it would technically be much faster?? Or am I reaching a bit here?
May 21, 2013 10:19 AM|BrockAllen|LINK
Darrel's got several good points (as per usual). I think eventually self-host will be more common, but IIS is what people know now. If perf (of the host) is an issue, then self host is worth the effort (but there will be leanring curve + effort in filling
in the missing pieces -- logging, whatever). If perf (of the host) isn't a major issue then, as I said before, I think for the forseeable future IIS will be what people generally use (since they're already using it for their ASP.NET, MVC, etc.).
Let us know what you end up choosing :)
May 21, 2013 10:20 AM|Darrel Miller|LINK
Is self-host faster? yes and no. Obviously many of the IIS components have been hardened and highly optimized. However parts of the ASP.NET pipeline are more tha 10 years old and can be memory hungry at times. You can probably strip out many of the IIS
features that you are not using and eek out more performance.
IIS is able to use kernel mode caching for which currently no self-host mechanism can do. IIS also has the ability to serve up static files using kernel mode code, which currently only one of the Owin hosts can do as far as I am aware. Also, you have to
be careful with the WCF self-host because under some scenarios heavy load can induce a bug in the .net thread pool which can significantly slow down responses.
So.... depending on your scenario either could be faster. However, with self-host you start with something very lightweight and it has the potential to be much better in the future. However, for heavy loads, IIS is probably more reliable today.
May 21, 2013 11:58 AM|trag1|LINK
Thank you both for you time and thoughts here. After some internal discussions it looks like we'll proceed the IIS route, but start looking into some self hosting with a smaller service and build up or knowledge on that before committing fully.