Multi-threading in Web Application (WCF / WebAPI)

Question

I have an "engine" that I want to expose via an HTTP layer (hosted with WebAPI / WCF).

This engine does some simple read only operations on large volumes of data and can really benefit from parallelism. A simple switch from for(...) to Parallel.For(...) does wonders.

Now I think we shouldn't do these kind of multi-threading in a web server, so I'm trying to figure out the best way to host this.

Ideally I'd like this to be hosted in IIS as a standard web app either with WebAPI or WCF. If this is not a good solution, what would be a good alternative?

Would it be to better to self host WebAPI or WCF in a standard Windows Service? I'm not sure if the issues here are IIS or ASP.NET specific.

Or maybe this is not a problem and I'm just worrying too much?

Any inputs would be appreciated.

Thanks

Answer 1

I'm not entirely clear what your concerns are but I'll try to give you some basis on which you can decide:

You can use multithreading in IIS/ASP.NET safely. Of course, with many parallel request you don't need that because the parallelism happens at a higher level (in fact, thoughput will slightly suffer, but only slightly). With few parallel requests though you can reduce latency using parallelism at a lower level ( Parallel.For ).

So multi-threading in ASP.NET is more about reducing latency than increasing throughput.

I don't see how self-hosting would change any of this.

You seem to have a little diffuse concerns that this is a viable approach. Try to formulate specific concerns and I'll address them.