I'm in the middle of performance testing a critical section of my project, when I notice a whole lot of extra threads being used to to perform WaitOrTimerCallback operations.
alt text http://lh4.ggpht.com/_p7-jVU64mGg/SZuWgUvTD7I/AAAAAAAAAEk/PUFrXrYvZh0/threads_thumb%5B1%5D.jpg?imgmax=800
On closer inspection I can see that these are being spawned by my ASMX client proxy class for operations on a remote server.
I was under the impression that these were using IO completion ports like all of my other asynchronous IO Calls.
Is it possible to get a ASMX or WCF proxy client to use IO Completion ports? If not - really what is the point?
[UPDATE]
The project was using ASMX proxy client(s). It appears that they are using the normal thread pool inorder to register a WaitOrTimerCallback. I'm now working with WCF Proxy clients. These are not spawning extra threads so i can only assume they are using the desired IO completion ports.
The ASMX Proxy class was created using Visual Studio 2008. I had added the following line to the the project file: "WebReference_EnableLegacyEventingModel>true" As the current flavour of ASMX clients do not have Asynchronous enabled by default.
I can't speak for ASMX, but WCF definitely does (and like you I'd be surprised if ASMX doesn't). Can you get the call stacks to ensure that they really are blocked on network calls (and not some other user code)?
Related
I have developed a WCF service for consumption within the organization's Ethernet.
The service is currently hosted on a windows-service and is using net.tcp binding.
There are 2 operation contracts defined in the service.
The client connecting to this service is a long running windows desktop application.
Employees(>30,000) usually have this client running throughout the week from Monday morning to Friday evening straight.
During this lifetime there might be a number of calls to the wcf service in question depending on a certain user action on the main desktop client.
Let us just say 1 in every 3 actions on the main desktop application would
trigger a call to our service.
Now we are planning to deploy this window service on each employee's desktop
I am also using `autofac` as the dependency resolver container.
My WCF service instance context is `PerSession`, but ideally speaking we have both the client and service running in the same desktop (for now) so I am planning to inject the same service instance for each new session using `autofac` container.
Now am not changing the `InstanceContext` attribute on the service implementation
because in future I might deploy the same service in a different hosting environment where I would like to have a new service object instance for each session.
Like mentioned earlier the client is a long running desktop application and I have read that it is a good practise to `Open` and `Close` the proxy for each call but if I leave the service to be PerSession it will create a new service instance for each call, which might not be required given the service and client have a 1-1 mapping. Another argument is that I am planning to inject the same instance for each session in this environment, so Open & Close for each service call shouldn't matter ?
So which approach should I take, make the service `Singleton` and Open Close for each call or
Open the client-side proxy when the desktop application loads/first service call and then Close it only when the desktop application is closed ?
My WCF service instance context is PerSession, but ideally speaking we have both the client and service running in the same desktop (for now) so I am planning to inject the same service instance for each new session using autofac container
Generally you want to avoid sharing a WCF client proxy because if it faults it becomes difficult to push (or in your case reinject) a new WCF to those parts of the code sharing the proxy. It is better to create a proxy per actor.
Now am not changing the InstanceContext attribute on the service implementation because in future I might deploy the same service in a different hosting environment where I would like to have a new service object instance for each session
I think there may be some confusion here. The InstanceContext.PerSession means that a server instance is created per WCF client proxy. That means one service instance each time you new MyClientProxy() even if you share it with 10 other objects being injected with the proxy singleton. This is irrespective of how you host it.
Like mentioned earlier the client is a long running desktop application and I have read that it is a good practise to Open and Close the proxy for each call
Incorrect. For a PerSession service that is very expensive. There is measurable cost in establishing the link to the service not to mention the overhead of creating the factories. PerSession services are per-session for a reason, it implies that the service is to maintain state between calls. For example in my PerSession services, I like to establish an expensive DB connection in the constructor that can then be utilised very quickly in later service calls. Opening/closing in this example essentially means that a new service instance is created together with a new DB connection. Slow!
Plus sharing a client proxy that is injected elsewhere sort of defeats the purpose of an injected proxy anyway. Not to mention closing it in one thread will cause a potential fault in another thread. Again note that I dislike the idea of shared proxies.
Another argument is that I am planning to inject the same instance for each session in this environment, so Open & Close for each service call shouldn't matter ?
Yes, like I said if you are going to inject then you should not call open/close. Then again you should not share in a multi-threaded environment.
So which approach should I take
Follow these guidelines
Singleton? PerCall? PerSession? That entirely depends on the nature of your service. Does it share state between method calls? Make it PerSession otherwise you could use PerCall. Don't want to create a new service instance more than once and you want to optionally share globals/singletons between method calls? Make it a Singleton
Rather than inject a shared concrete instance of the WCF client proxy, instead inject a mechanism (a factory) that when called allows each recipient to create their own WCF client proxy when required.
Do not call open/close after each call, that will hurt performance regardless of service instance mode. Even if your service is essentially compute only, repeated open/close for each method call on a Singleton service is still slow due to the start-up costs of the client proxy
Dispose the client proxy ASAP when no longer required. PerSession service instances remain on the server eating up valuable resources throughout the lifetime of the client proxy or until timeout (whichever occurs sooner).
If your service is localmachine, then you consider the NetNamedPipeBinding for it runs in Kernel mode; does not use the Network Redirector and is faster than TCP. Later when you deploy a remote service, add the TCP binding
I recommend this awesome WCF tome
I built a application with 5 wcf services and hosted them in IIS 7.5. I used the default configuration for the net.Tcp port (808*).
I am not used to host WCF services in IIS (I always hosted in Windows Services) and I found interesting that when I call the service (using tcp binding) I got two different process on the server.
One is SMSvcHost.exe (the one that is actually using the 808 port) and the other is w3wp.exe wich I think is handling a instance of the server I am calling.
I have a lot of questions so I will enumerate them:
Should I use IIS instead of Windows Service to host WCF Services (tcp binding) ?
The fact that I have two processes to answer my request means that I may have cpu impacts ?
Sometimes my services stop answering using the tcp binding. I got a timeout error on my clients but the mex is correctly answering if I go to the http://myServer/Service1.svc. I suspect that this problem is caused by fault connections but I am throwing exceptions correctly (using fault exceptions) and catching them correctly on my clients. Besides, I am also implementing a partial class for every service to dispose corretly (either using Close or Abort methods). Is there any way to figure out what's going on when the services stop answering ?
Shouldn't the w3wp.exe processes be closed after the client ends the request ? They remain on the Task Manager even when no one is using the services. I guess this is the reason of why my Entity Library logging locks the file after my request is completed.
Ideally it would be better hosted in Windows Activation Services (WAS) which is close to what you think of as IIS, but not quite. Here's a good introductory article on MSDN magazine:
http://msdn.microsoft.com/en-us/magazine/cc163357.aspx
I am writing card game using Silverlight and HttpPollingDuplex.
I have 4 seperate http duplex services, which can be called from my game (silverlight client)
1. ChatService
2. AuthService
3. LobbyService
4. GameService
After I host the game under IIS 7.5 I note with Fiddler that Silverlight client do polling requests sequentially, and my application become very slow, because for example for getting message from chat service client have to wait until other services polling will be finished. Than I changed serverPollTimeout for services to finish pollings faster, now my game works faster, but do continues requests to services sequentially. so the question is
Is it possible to create client proxy or configure client to do polling queries parallel in case of more than one polling service? and if not is changing serverPollTimeout good practice in my case? or what will be the best configuration for me?
Creating proxy and calling service methods in separate thread doesn't help :(
Thanks a lot!
Here is my workout if someone has the same problem
There is a limit to how many HTTP connections Silverlight can use in the browser, If all the services live on the same host://name:port, there should be only one onging polling connection to it, no matter how many services are hosted there.
I created sub domains for each service, which solves the problem
Another solutions is set created instance as a static property.
Imagine the following setup: a Silverlight client tunnels a serialized command over the network using a WCF service which in turn deserializes the command and sends it using NServiceBus to a generic host which is responsible for processing the command. The WCF service has - upon sending the command - registered a callback to be invoked. The generic host validates the command and 'returns' an error code (either 0 == success or >0 == failure).
Note: The WCF service is modelled after the built-in WCF service. The difference is that this WCF service receives a 'universal command' (not an IMessage), deserializes it into a real command (which does implement IMessage), and consequently sends the deserialized command off to the bus.
When unexpected exceptions occur, the command gets (after a certain amount of retries) queued in an error queue. At this point, the initiating WCF service sits there idle, unaware of what just happened. At some later point, the Silverlight client will time out according to the WCF client proxy configuration.
Things which are fuzzy in my head:
Does NServiceBus handle this scenario in any way? When does the timeout exception get thrown (if at all)? Or is this something exclusive to sagas?
Presuming I use [OperationContract(AsyncPattern=true)], are there any WCF related timeout settings that will kill the service operation? Or will the EndXXX method be somehow called? Or will it sit there forever, leaking, waiting for something that will never come?
Ways to proceed:
reuse existing timeout mechanisms, provided things don't leak.
build my own timeout mechanism between the wcf service and nservicebus.
notify the wcf service somehow when the command lands in the error queue.
build my own async notifcation mechanism using full blown callback message handler in the WCF service layer.
Things I've done:
run the example provided with NServiceBus.
spiked the happy case.
Any guidance on how to proceed is welcome, be it blog post, mailing list entries, ...
Some motivations for picking my current approach
I'm trying to leverage some of the scalability advantages (using distributor in a later phase) of NServiceBus.
I don't want to host a gazillion WCF services (one for each command), that's why I cooked up a bus-like WCF service.
Even though this is somewhat request/response style, I'm mostly concerned with gracefully handling a command reply not coming through.
You can develop any sort of message type you desire, IMessage is simply a marker interface. If you inspect the WSDL file that the service mex endpoint provides, there is no reference to IMessage, therefore you can define any command you like in you service. That being the case you should be able to use the provided WCF host.
I was able to reproduce the issue you describe using the built-in WCF hosting option. When an exception is thrown, the entire transaction is rolled back and this includes the Bus.Return, and therefore the service never gets a response.
I found a hack around this that I could provide, but I recommend reconsidering how you are using the service. If you are truly looking to do some expensive operations in a separate process then I would recommend in your WCF endpoint that you do a Bus.Send to a different process altogether. This would ensure to your client that the command was successfully received and that work is in progress. From there it would be up to the server to complete the command(some up front validation would help ensure its success). If the command was not completed successfully this should be made known on another channel(some background polling from the client would do).
So I'll be providing a few functions via a self hosted (in a WindowsService) WebServiceHost (not sure how to process HTTP GET/POST with ServiceHost), one of which may be called a large amount of the time. This function will also rely on a connection in the appdomain (hosted by the WindowsService so it can stay alive over multiple requests).
I have the following concerns and would be oh so thankful for any input/thoughts/comments:
Concurrent access - how does the WebServiceHost handle a bunch of concurrent requests. Are they queued and processes sequentially or are new instances of the contracts automagically created?
WebServiceHost -> WindowsService communication - I need some form of communication from the WebServiceHost to the hosting WindowsService for things like requesting a new session if one does not exist. Perhaps implementing a class which extends the WebServiceHost with events which the WindowsService subscribes to... (unless there is another way I can set off an event in the WindowsService when a request is made...)
Multiple WebServiceHosts or Contracts - Would it give any real performance gain to be running multiple WebServiceHost instances in different threads (one per endpoint perhaps?) - A better understanding of the first point would probably help here.
WSDL - I'm not sure why (probably just need to do more reading), but I'm not sure how to get the WebServiceHost base endpoint to respond with a WDSL document describing the available contract. Not required as all the operations will be done via GET requests which will not likely change, but it would be nice to have...
That's about it for the moment ;) I've been reading a lot on WCF and wish I'd gotten into it long ago, but definitely still learning.
Concurrent access - this is something you can set using ServiceBehaviorAttribute. there are a number of options -- you can have WCF create a new instance of your service class for each incoming request, or you can have a single instance handle all requests. Additionally you can tell WCF whether to pass you the requests serially or concurrently.
WebServiceHost -> WindowsService communication. Two approaches spring to mind: WCF supports a mode called "well known instance" where you pass an instance of your service to the ServiceHost constructor instead of passing a Type and letting WCF instantiate it for you. With this mode you can preconfigure your service instance with a reference back to your hosting code (alternatively you could use events). An alternative if you want to preserve instancing flexibility would be to have a static method in your hosting code that the WCF service could call back into.
Multiple WebServiceHosts or Contracts - really no advantage to having more than one ServiceHost instance. see also this SO thread: What are the benefits for several servicehosts? Does one ServiceHost support several simultaneous connections on one endpoint?.
WSDL - While you can enable WSDL by turning on metadata publishing (http://msdn.microsoft.com/en-us/library/ms788760.aspx), WSDL support is intended for SOAP-based services, not pure HTTP GET/POST. The WSDL that gets auto-generated for your service will likely not be very useful.