ManualResetEventSlim 信号是否会降低性能？

Question

我正在使用 ManualResetEventSlim 在我的应用程序中使用信号机制，如果请求/秒为 100，它会很好。随着我增加请求/秒，它会变得更糟。

例子：

100 个请求/秒 -> 90% 的事务在 250 毫秒内完成，吞吐量（成功请求/秒）为 134。

150 请求/秒 -> 90% 的事务在 34067 毫秒内完成，吞吐量（成功请求/秒）为 2.2。

我使用 ConcurrentDictionary 如下所示：

// <key, (responseString,ManualResetEventSlim) >
private static ConcurrentDictionary<string, (string, ManualResetEventSlim)> EventsDict = new ConcurrentDictionary<string, (string, ManualResetEventSlim)>();

下面给出的过程描述了对 ManualResetEventSlim 的需求（ Api 解决方案 1和Api 解决方案 2完全是：

1. Api 解决方案 1（REST Api）收到一个请求，它在 ConcurrentDictionary 中针对一个键添加一个元素（null，ManualResetEventSlim），并使用 async/await 调用第三方服务（SOAP）。 第三方 soap api 返回确认响应，但实际响应待定。 得到确认响应后，转到 ManualResetEventSlim.wait

2. 一旦第三方处理了请求，它就会使用公开的方法调用Api 解决方案 2 (SOAP)并发送实际响应。 Api 解决方案 2 通过发出 http 请求向Api 解决方案 1 (REST Api)发送响应，然后将数据插入数据库以进行审计日志。

3. Api 解决方案 1将从响应字符串中获取密钥并更新 ConcurrentDictionary 中的响应字符串并设置信号。

4. Api 解决方案 1在向客户端返回响应之前处理 ManualResetEventSlim object。

Answer 1

我认为，您应该能够通过将(string, ManualResetEventSlim)替换为TaskCompletionSource<string>来摆脱阻塞代码：

在解决方案 1 中，您将执行以下操作：

TaskCompletionSource<string> tcs = new TaskCompletionSource<string>()
EventsDict.AddOrUpdate( key, tcs );
await KickOffSolution2ThirdParty( /*...*/ );
string result = await tcs.Task; // <-- now not blocking any thread anymore

和对方：

void CallbackFromSolution2( string key, string result )
{
     if( EventsDict.TryRemove(key, out TaskCompletionSource<string> tcs )
     {
         tcs.SetResult(result);
     }
}

这当然只是这个想法的粗略轮廓。 但希望足以让我的思路可以理解。 我现在无法对此进行测试，因此欢迎任何改进/更正。