C# Web应用程序中的多线程（WCF/WebAPI）

我有一个“引擎”，我想通过HTTP层（由WebAPI/WCF托管）公开它

该引擎对大量数据执行一些简单的只读操作，并可以从并行性中获益。从for（…）到Parallel的简单切换。for（…）确实很神奇

现在，我认为我们不应该在web服务器中执行这种多线程，所以我正在尝试找出最好的方法来承载它

理想情况下，我希望将其作为标准web应用程序托管在IIS中，使用WebAPI或WCF。如果这不是一个好的解决方案，那么什么是一个好的替代方案

在标准Windows服务中自行托管WebAPI或WCF会更好吗？我不确定这里的问题是IIS还是ASP.NET特有的

或者这不是问题，我只是担心太多了

如有任何意见，将不胜感激

---

谢谢

我不完全清楚您的担忧是什么，但我会尝试给您一些基础，您可以根据这些基础做出决定：

您可以在IIS/ASP.NET中安全地使用多线程。当然，对于许多并行请求，您不需要这样做，因为并行性发生在更高的级别上（事实上，thoughput会受到轻微影响，但只会受到轻微影响）。虽然并行请求很少，但您可以在较低级别上使用并行来减少延迟（

parallel.For

）

因此，ASP.NET中的多线程更多的是减少延迟，而不是增加吞吐量

我不认为自我托管会改变这一切

---

你似乎有点担心这是一个可行的方法。试着提出具体的问题，我会解决它们。

谢谢，并为这个定义不清的问题道歉。我当时的印象是（现在很难找到引用），通过在web应用程序中创建线程，我们可以从IIS用于服务请求的同一线程池中分配线程。因此，如果我们增加并发用户的数量，我们更有可能耗尽线程池，这基本上会阻止IIS服务新请求。现在，如果两个线程池不同，这显然是不适用的。这更有意义吗？a）ASP.NET和任务的线程池是相同的，但只要应用程序没有过载，这就不是问题。如果它过载，不管线程如何，这都是一个需要解决的问题。并行性不会使重载（明显）变得更糟。b） 您可以使用TaskScheduler API使用第二个线程池，但这并不能解决重载问题。没有帮助。我还需要解决其他问题吗？