Does the hosting option affects the amount of requests a WCF service can handle?
-
Hard to say - the main reason for self-hosting is probably having more control, e.g. being able to tweak the system as you need it.
IIS hosting is convenient and easy to set up, and it offers "on-demand" loading of the service, e.g. the service host is only loaded if a request actually comes in.
This constant loading (and unloading) of the service host will probably hurt performance a little bit - on the other hand, self-hosting a service host, you probably use more memory (since the ServiceHost is active and in memory at all times).
So again - it's a memory-vs-speed trade-off - selfhosting uses more RAM but is probably a tiny bit faster.
Marc
-
Once the service is running I would expect no significant difference.
But, as with any performance question, you can only get a useful answer by testing your service in both cases with realistic loads and looking at the big picture. E.g. one might server a few more requests but at a slightly higher memory cost.
There are of course going to be other differences e.g. IIS hosting, with on demand instantiation, would be expected to be a little slower to serve the first request from idle, whether this is significant only you can tell.
marc_s : Of course, if you host in IIS and you have the recommended "per-call" activation model, IIS will (in the worst case) keep creating ServiceHost instances over and over again. Once the ServiceHost is up, I agree - no difference to be expected. -
Once "Dublin" (a purpose built WCF hosting environment) is released, it will be natural to use that.
EDIT: This answer was originally about the potential difference between IIS and self hosted due to differences in threading. However, I stand corrected, see the comment below.
marc_s : self-hosted WCF is just as multi-threaded as hosting it in IIS - I don't see any benefit pro IIS here.
0 comments:
Post a Comment