Dapper查询时间随着并发操作而大大增加

Question

我已经建立了.NET Core 3.1 API。该API进行了大量工作，其中大部分正在执行SQL查询。大多数API使用EF Core进行数据访问。但是，对于一个特别关键的查询，我们发现Dapper具有明显的性能优势。

我们正在测试的一种测试场景涉及每秒调用许多请求的API。以线性方式进行测试时，请求花费的时间不到一秒钟。但是，如果我们在一秒钟内用10、15（最多120）个调用轰炸API，查询性能就会下降。例如，线性查询大约需要500毫秒。在15次快速呼叫（在一秒钟左右）中，平均查询时间为3600毫秒。 确实，在“宽”方案中，有效吞吐量

增加

。但是，我看不到数据库是这里的瓶颈，我想知道为什么当许多请求在短时间内继续进行时，请求会花这么长时间？[另一个需要注意的关键点是，如果我交替调用环境和本地设备中托管的API，则性能和吞吐量将提高30％左右。这使数据库本身不是主要问题的理论得到了证实。我也发现只有this question接近我要问的内容，并且重点放在EF上。

Dapper的使用方式不显眼。尽管我已经尝试过单例和瞬态，但EF上下文具有典型的生存期（范围）。外观如下：

using (var conn = new SqlConnection(_connectionString)) //from EF properties
{
    using (var tx = await conn.BeginTransactionAsync(System.Data.IsolationLevel.ReadUncommitted))
    {
        var details = conn.QueryAsync<OurObject>(
    @"SELECT columns
    FROM table1
    INNER JOIN table2
    WHERE (someConditional = @paramValue)"
    , new
    {
        paramValue
    },tx);
        var res1 = Success((await details).ToList());
        return res1;
    }
}

应注意，出于特定原因，我们需要使用此隔离级别和事务。我们正在从表中读取数据，然后为每个请求写信给它们。脏读比锁要少得多。

我们在整个请求生命周期中都有详细的日志记录，有效地显示了读取（在较小程度上是写入）所花费的时间更长。数据处理不会改变，并且在每个请求中都非常快。

最后，我知道这是一个比S.O上的许多问题更大的问题。感谢您提供的任何信息或尝试的东西！

我已经建立了.NET Core 3.1 API。该API进行了大量工作，其中大部分正在执行SQL查询。大多数API使用EF Core进行数据访问。但是，对于一个特别关键的查询，...

Answer 1

例如，线性查询大约需要500毫秒。在15次快速呼叫（在一秒钟左右）中，平均查询时间为3600毫秒。