I have an IIS hosted WCF service and it will take long time to serve a request at first time. Subsequent requests served very fast. I believe this is due to automatic activation in IIS. Is there any way to keep WCF service is always running? Or improve automatic activation time?
Use Auto-Start.
One of many references Google gave me:
How to use AppFabric Auto-Start feature to avoid warm-up delays for IIS-hosted WCF Receive Locations
Related
I am experiencing a strange issue in my browser hosted silverlight application. Call are made to a WCF routing service hosted in on IIS 7. The routing service then switches the protocol to nettcp and routes the request to another WCF service on our application server. This second service is hosted in a windows service. What I am noticing is that when a client on one machine invokes a long running request other users on the network cannot even get smaller requests serviced till the long running request returns. Has anyone experienced this or does anyone know what can be causing this?
What are the pros and cons of hosting a WCF service in IIS versus using a Windows service?
FYI - I have googled but it's surprisingly hard to find relevant answers.
We've just implemented a big WCF service, and did it as a self-hosted windows service. The reason we did it that way was our architects wanted the extra control you get from hosting your own and taking IIS out of the equation. Basically, when you go the self-hosted route,
you process each request
you configure your own endpoints
you configure your certs
you control the exception handling
etc.
Our WCF service is industrial scale with rev proxies, load balancing and about 50 methods attached to the endpoints. And we use multiple encryption protocols depending on the types of devices connecting.
However, if I was doing a smaller WCF web service with just a single server, a single endpoint and a few method calls, I'd probably use IIS to manage the endpoint and implement the SSL letting the UI do the configuration work that would otherwise have to be done in code. It's just easier from what I've seen.
Long story short, if you host it, you control everything in code. If you're interested in a quicker delivery, I'd start with IIS.
As you may know, IIS 6+ can share port 80 with other HTTP applications running in different processes.
However my self-hosted WCF service seems to take IIS offline. When the WCF service is running, all HTTP requests go to the service. When I stop the service, all HTTP requests go to IIS. This is despite the fact that the two applications are using very unique URI paths. What's the deal? How do I get them to play together nicely?
EDIT:
My WCF service uses a custom binding with an HttpTransportBindingElement
Sorry if this belongs on serverfault. I'm not sure if it's a configuration issue or code issue.
After a lot more experimentation, I've come to a conclusion.
It looks like the problem is caused when the endpoint base address of the WCF service is the same as the base address of IIS. In other words if an endpoint exists at http://localhost/, it will take over and handle all incoming HTTP requests.
So even if your WCF subpaths are different from IIS, the base endpoint address has to be something other than http://localhost/.
We have a WCF service, hosted on IIS7.5, that has to fetch some data from an external web service.
Is there some way to schedule this action to be started, in our WCF service, on a regular (timed) basis?
Thanks
Yes, create a Windows service which wakes up every x minutes or hours and makes the call.
The WCF service is not "always on" - it is typically only created when a request comes in and needs to be handled. But you would typically host your WCF service in either IIS, or self-host - which usually already means a Windows Service anyway.
I would recommend VisualCron which can schedule WCF and web service calls (amont other things).
With that tool you can supply dynamic parameters, retrieve output and parse it. If you want you can forward the data to a file, email etc.
I have a WCF Service hosted as Windows Service and client is an ASP.Net application consuming WCF Service methods.
In process of implementing security, I am confused over which among netTcpBinding/wsHttpBinding will be suitable for my case.
Most likely all the applications in scene (WCF Service, Windows Service, ASP.Net Website) will be sitting on different servers in our office, thus in an Intranet. ASP.Net website will be accessed by users over Internet.
Though, I can always use wsHttpBinding here, will it be suitable to set the service endpoint using netTcpBinding in my case?
Check this out for a comparison of all the different built in bindings:
Configuring System-Provided Bindings - MSDN
As for your case, as long as it's the web server contacting the WCF service and you don't need to provide an endpoint for any external consumers of the service...netTcpBinding should be up to the job.
You can expose your service over more than one binding if you wish, so you could actually use both.
However, if you control both client and service and they both use WCF, netTcpBinding is much faster. Unless you have a firewall between those two, I would choose that.
Use netTcpBinding instead wsHttpBinding if you are willing to trade interoperability for performance knowing that you can easily cancel the trade if you are not satisfied with the results (it's a matter of changing config values).
Since your WCF Services will be accessed by applications sitting in your office (INTRANET), I would go with netTcpBinding.
In an intranet scenario, it is recommended that you use netTcpBinding unless you have a specific requirement to use other bindings such as wsHttpBinding. By default, netTcpBinding uses binary encoding and transport security, which delivers better performance.
Following URLS will help to get more information
http://msdn.microsoft.com/en-us/library/cc949026.aspx
http://msdn.microsoft.com/en-us/library/ms730879.aspx
Since your WCF service is a windows service +1 for netTcpBinding. Hosting netTcpBinding on IIS is difficult.