c# - 尝试通过控制同时请求来解决可伸缩性问题

Question

我有一个遗留应用程序需要处理可扩展性问题。这是一个 WCF 服务，它监听从后端系统收到的请求，并根据这些请求对数据进行一些计算/处理。计算不是 CPU 密集型的，尽管在某些情况下它会调用一些第三方库 API(它本身调用基于 SOAP 的 Web 服务)。不涉及任何数据库调用。以下是服务的设置方式。

[ServiceContract]
public interface IMyService
{
    [OperationContract]
    ProcessingResult ProcessData(int dataId, string dataDescription);
}


[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Multiple, IncludeExceptionDetailInFaults = true)]
public class MyService : IMyService
{

    ProcessingResult ProcessData(int dataId, string dataDescription)
    {
         // Some data processing using third party library APIs and return ProcessingResult instance.

    }
}

public class ProcessingResult
{
    public int Code;
    public string Message;
}

这里的问题是在负载条件下，有太多的 ProcessData 方法调用使系统过载。在这些场景中，我见过数百个线程同时运行。他们最终确实完成了任务，但系统速度急剧下降。为了处理它，我正在考虑添加某种门控机制。类似于将工作委托(delegate)给另一个类，该类将处理数据调用排队到线程池，同时处理的最大请求数为阈值。我看到这种方法的问题是 ProcessData 仍然需要等待线程池中排队的工作完成，然后才能返回 ProcessingResult 实例。

谷歌搜索似乎表明 async-await 可能是一个不错的模式，但是，我几乎没有受到限制，因为这个应用程序没有使用最新和最好的 .net 版本，迁移到更新的 .NET 版本可能是一个很大的要求在此刻。关于如何在此类中使用 ThreadPool.QueueUserWorkItem 机制并能够等待特定项目完成的任何建议？

Answer 1

如果您需要同时处理数百个请求，那么非阻塞 IO 就很重要。它消除了对这么多线程的需求。在 .NET 3.5 中没有方便的选项来执行此操作。如果您能升级到 4.0，故事就会好 10 倍。

我在 4.0+ 中会做的是:

static SemaphoreSlim sem = new SS(100); //max 100 concurrent requests
async Task<ProcessingResult> ProcessData(...) {
 await sem.WaitOne();
 await ProcessRequestAsync(); //or, do it synchronously here if convenient
 sem.Release();
}

在 4.0 之前的版本中，您需要找到一种非阻塞方式来执行信号量提供的限制。这可能涉及使用 IAsyncResult。

或者，您在 WCF 中找到一种方法来限制并发请求的最大数量。这也能解决问题。

即使您卸载到后台线程，这对您的帮助也很小:您需要将 IAsyncResult 公开给 WCF，以便 WCF 线程可以解除阻塞。

there are so many calls of ProcessData method that overloads the system. In these scenarios,I have seen hundreds of threads running at a time.

这里出现问题的原因是什么？太多线程或太多并发操作使后端重载？如果是前者，那么快速且完全有效的解决方法是增加线程池限制。 1000 个线程不会在我的测试中引起问题。如果后端过载，也取消限制线程池并使用同步信号量来限制并发后端调用的数量。

所以这里有一些可供选择的选择。最好的方法是异步 IO 和等待，但这更难实现。