How to make time-costing web service Asynchronous?

[Morgan Cheng]

I have one webservice that involves time-costing computation. For each
request, it consumes about 2 seconds computation. Since ASP.NET has 25
threads per CPU to handle requests, this delay turns to be bottleneck
if webservice is synchronous. Say, the webserivce is called ABC, then
one thread is arranged for one call to ABC, and the thread is not
released until the result is returned.

I once configured to implement it as Asynchronous webmethod. That is,
implement BeginABC and EndABC webmethod. But, it seems asynchronous
webmethod only fit for handle I/O or invocation to other webservice.
The time-costing computation is local and is not I/O. So,
Delegate.BeginInvoke is used; but this also involves ThreadPool and no
benefits at all.

Any idea to design such time-costing-computation webserivce with high
throughput?
Thanks in advance.
Morgan

[Peter Duniho]

On Wed, 27 Jun 2007 18:28:56 -0700, Morgan Cheng
<mo************@gmail.comwrote:

[...]
I once configured to implement it as Asynchronous webmethod. That is,
implement BeginABC and EndABC webmethod. But, it seems asynchronous
webmethod only fit for handle I/O or invocation to other webservice.
The time-costing computation is local and is not I/O. So,
Delegate.BeginInvoke is used; but this also involves ThreadPool and no
benefits at all.

Any idea to design such time-costing-computation webserivce with high
throughput?

Well, one solution would be to create your own thread pool, independent
from the main application thread pool, and use that to service your
requests. That way, those time-consuming requests don't eat up the main
thread pool. Of course, it still makes sense to not let your special
thread pool get too big (25 threads per CPU is a nice number), and so if
you get too many of those requests, they will wind up queued. But at
least they won't be interfering with other types of requests.

Alternatively, you could just have a single non-pool thread (or maybe a
much smaller pool, with a number of threads equal to the number of CPUs,
plus a couple) that services a queue of those requests. After all, if the
requests are CPU-bound (you said it's not i/o), it's not like having 25
threads per-CPU is going to make things faster (in fact, it will make
things slower). Better to just put them all in a queue and process them
sequentially.

Pete