How Expensive are ???-Hosted WCF Services?

Question

A co-worker and I are having a discussion about WFC services when the topic of "cost" comes up.

The question is this:

Given that an IIS-hosted WCF service and a Windows-Service-hosted WCF service do the exact same thing, which service will be more "expensive" with regard to memory and CPU cycles if they both are accepting the same load?

We are not concerned about initial start-up coding, installation or configuration (to which IIS seems geared to provide a simpler experience), just the bare-bones cost of running the services.

Jehoash

Answer 1

I cannot provide concrete figures, though if this is big concern, you should definitely do performance testing to be sure. For a typical HTTP-based WCF service, all requests will be initially handled by http.sys inside Windows, and then dispatched to the appropriate process. Whether or not your service is hosted in IIS or standalone will not matter nearly as much as the WCF-specific configuration settings you use, with respect to per-call, per-session or singleton configuration, and request size limits and request throttling.

I would focus on usability and what makes more sense than strictly on performance numbers, since they should be nearly the same.

Bottom line: use whatever is more convenient, performance test when necessary.

Flynn

OK.. So I agree that any true bottleneck would come of the type of binding used, specific settings in the config. After a while using WCF in both service styles, I have come to agree that performance is due to factors other than the service contents and much more to do with the config style. Thanks Brad. – Jehoash

Answer 2

One very significant performance consideration between IIS or Windows service based hosting for WCF, is binding type. IIS only supports WCF bindings which function over HTTP, such as wsHttpBinding. basicHttpBinding, etc.

Non-Http bindings are generally known to have better performance, such as the netTcpBinding (requires both service and client to be WCF-based I believe) or netNamedPipeBinding (fastest, but service/client must be on same machine). These of course have their own limitations, especially with flexibility.

Here's a good overview: http://weblogs.asp.net/spano/archive/2007/10/02/choosing-the-right-wcf-binding.aspx

There has been a very similar discussion here: WCF Binding Performance

Horaciohorae

Answer 3

I know this doesn't answer your question completely, but I would like to share my experience.

I have a windows console application that when scheduled is calling WCF services hosted in IIS. In this architecture the IIS is actually completely unnecessary and just an additional component to the overall solution. It was really included in the solution for marketing reasons, to beef up the product, and not for technical reasons.

These are the main problems I am facing, and why I would have avoided using IIS if I could for technical reasons, and this applies to my experience. Please note: I am not saying hosting WCF services in IIS is a bad idea. I am just giving my thoughts from the product I am working on at present.

1. Having IIS in the loop means having another system in the overall solution. This in turn adds complexity to your deployment. Some clients have IIS6 others run 7. While these differences might seem small on the surface. Make no mistake, they're still different, meaning you're adding more potential for environment differences if you're deploying your product to different clients. DO NOT underestimate these differences. Ive even have clients trying to run my WCF services inside a SharePoint Site Collection (duh!) the point is A LOT more than you think can go wrong.
2. IIS also has an AppPool consideration, which might need to be configured depending on the complexity of your product. That AppPool needs an identity to run under, adding more complexity again to your overall solution.
3. I've had some issues where a single threaded service sometimes has "interesting" - Thread abort messages. While I'm still trying to figure out the exact cause, in the back of my mind I'm sincerely hoping this isn't somehow IIS related. The point is I wouldn't have this consideration if I eliminated IIS from the overall solution.
4. I've heard discussions that IIS is a more robust hosting environment for WCF services vs self hosted. I am not entirely sure this holds any weight. If you know what you're doing there should be no reason for your self hosted service to be unreliable. But I guess it is more work upfront to implement some of the automatic features you get in IIS, for example WP recycling.
5. I'm not overall dissatisfied with IIS in the loop, but its a pain when I hand the product over for deployment, and consultants without a strong technical background have to set up the IIS application. Usually something can and will go wrong, and involves someone with more technical experience to step in and solve. If you're self hosting you can much more easily package your app for deployment.
6. Sorry to reiterate but if you go for IIS, you'll have 2 applications in your solution rather than 1, even though the business side of your organisation will only see the app as one business unit, essentially not understanding the full complexity of the solution you're implementing. For example: Why do we have 2 configuration files? Why do we have to configure mail twice? Why do we have to deploy DLLs to 2 locations. These questions get asked a lot.
7. Lastly I thought I would mention if you're working remotely or over VPN to deploy to clients, the situation gets even worse, sometimes the consultant has access to sensitive areas you don't. As a developer try to eliminate as much extra baggage as possible from your overall solution. Lets also mention the sys admin might at times issue a convenient IIS reset, if your app is hosted alongside others, they'll reset your services.

Less systems in my experience = less can go wrong. But you need to decide if you have the skills to implement reliable self hosted services. This all in turn directly relates to the cost of development, deployment and maintenance.

Hottempered