I have a web service, implemented with WCF and hosted in IIS7, with a submit-poll communication pattern. An initial request is made, which returns quickly and kicks off a background process. The client polls for the status of the background process. This interface is set and can’t be changed (it’s a simulation of an external service we depend on).
I implemented the background processing by adding another service contract to the existing service with a one-way message contract that starts the long-running process. The “background” service keeps a database updated with the status in order to communicate with the main service. This avoids creating any new web services or items to deploy.
The problem is that the background process is very CPU intensive, and it seems to be starving the other service calls out. It will take up an entire processor, and while a single instance of the background process is running, status polling calls to the main service can take over a minute. I don’t care how long the background process takes.
Is there any way to throttle the resource usage of the background method? Or an obvious way to do long running async processes in WCF without changing my submit/poll service contract? Would separating them into different web services help if the two services were still running on the same server?
The first thing I would try would be to lower the priority.
If you’re actually spinning off a separate process for the background work, then you can do it like this:
If it’s really just a background thread, use this instead (from within the thread):
(Actually, it’s better to start the thread suspended and change the priority at the caller before running it, but it’s generally OK to lower your own priority.)
At the very least it should help determine whether or not it’s really a CPU issue. If you still have problems after lowering the priority then it might be something else that’s getting starved, like file or network I/O.