c# - 使用具有大数据的 SqlCommand 异步方法的糟糕性能

Question

使用异步调用时，我遇到了主要的 SQL 性能问题。我创建了一个小案例来演示这个问题。

我在驻留在我们 LAN 中的 SQL Server 2016 上创建了一个数据库(所以不是 localDB)。

在那个数据库中，我有一个表 WorkingCopy有 2 列:

Id (nvarchar(255, PK))
Value (nvarchar(max))

DDL

CREATE TABLE [dbo].[Workingcopy]
(
    [Id] [nvarchar](255) NOT NULL, 
    [Value] [nvarchar](max) NULL, 

    CONSTRAINT [PK_Workingcopy] 
        PRIMARY KEY CLUSTERED ([Id] ASC)
                    WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, 
                          IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, 
                          ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

在那个表中，我插入了一条记录( id ='PerfUnitTest', Value 是一个 1.5mb 的字符串(一个更大的 JSON 数据集的 zip))。

现在，如果我在 SSMS 中执行查询:

SELECT [Value] 
FROM [Workingcopy] 
WHERE id = 'perfunittest'

我立即得到了结果，我在 SQL Servre Profiler 中看到执行时间约为 20 毫秒。一切正常。

使用普通 SqlConnection 从 .NET (4.6) 代码执行查询时:

// at this point, the connection is already open
var command = new SqlCommand($"SELECT Value FROM WorkingCopy WHERE Id = @Id", _connection);
command.Parameters.Add("@Id", SqlDbType.NVarChar, 255).Value = key;

string value = command.ExecuteScalar() as string;

这个的执行时间也是大约 20-30 毫秒。

但是当将其更改为异步代码时:

string value = await command.ExecuteScalarAsync() as string;

执行时间突然 1800 毫秒 !同样在 SQL Server Profiler 中，我看到查询执行持续时间超过一秒。虽然分析器报告的执行查询与非 Async 版本完全相同。

但情况会变得更糟。如果我在连接字符串中使用数据包大小，我会得到以下结果:

Packet size 32768 : [TIMING]: ExecuteScalarAsync in SqlValueStore -> elapsed time : 450 ms

Packet Size 4096 : [TIMING]: ExecuteScalarAsync in SqlValueStore -> elapsed time : 3667 ms

Packet size 512 : [TIMING]: ExecuteScalarAsync in SqlValueStore -> elapsed time : 30776 ms

30,000 毫秒 !!这比非异步版本慢 1000 多倍。 SQL Server Profiler 报告查询执行时间超过 10 秒。这甚至无法解释其他 20 秒去哪儿了!

然后我切换回了同步版本，并尝试了数据包大小，虽然它确实对执行时间产生了一点影响，但它没有异步版本那么引人注目。

作为旁注，如果它只将一个小字符串(< 100 字节)放入值中，则异步查询执行与同步版本一样快(结果为 1 或 2 毫秒)。

我真的对此感到困惑，尤其是因为我使用的是内置 SqlConnection ，甚至不是 ORM。此外，在四处搜索时，我没有发现任何可以解释这种行为的原因。有任何想法吗？

Answer 1

在没有显着负载的系统上，异步调用的开销稍大。尽管 I/O 操作本身无论如何都是异步的，但阻塞可能比线程池任务切换更快。

多少开销？让我们看看你的计时数字。阻塞调用为 30 毫秒，异步调用为 450 毫秒。 32 kiB 数据包大小意味着您需要大约 50 个单独的 I/O 操作。这意味着我们在每个数据包上有大约 8 毫秒的开销，这与您对不同数据包大小的测量结果非常吻合。尽管异步版本需要做比同步更多的工作，但这听起来并不像是异步的开销。听起来同步版本是(简化)1 个请求 -> 50 个响应，而异步版本最终是 1 个请求 -> 1 个响应 -> 1 个请求 -> 1 个响应 -> ...，一遍又一遍地支付成本再次。

越来越深。 ExecuteReader效果和 ExecuteReaderAsync 一样好.接下来的操作是Read后跟一个 GetFieldValue - 在那里发生了一件有趣的事情。如果两者中的任何一个是异步的，则整个操作都很慢。所以一旦你开始让事情真正异步，肯定会发生一些非常不同的事情 - Read会很快，然后是异步 GetFieldValueAsync会很慢，或者你可以从慢 ReadAsync 开始，然后都是 GetFieldValue和 GetFieldValueAsync很快。从流中的第一次异步读取速度很慢，并且速度完全取决于整行的大小。如果我添加更多相同大小的行，读取每一行所需的时间与我只有一行的时间相同，因此很明显数据仍在逐行流式传输 - 它似乎更喜欢读取整个开始任何异步读取后立即行。如果我异步读取第一行，然后同步读取第二行 - 读取的第二行将再次快速。

所以我们可以看到问题是单个行和/或列的大小很大。您总共拥有多少数据并不重要 - 异步读取一百万小行与同步读取一样快。但是只添加一个太大而无法放入单个数据包的字段，并且您会神秘地产生异步读取该数据的成本 - 好像每个数据包都需要一个单独的请求数据包，而服务器不能只发送所有数据一次。使用 CommandBehavior.SequentialAccess确实按预期提高了性能，但同步和异步之间的巨大差距仍然存在。

我得到的最好的表现是正确地完成整个事情。这意味着使用 CommandBehavior.SequentialAccess ，以及明确地流式传输数据:

using (var reader = await cmd.ExecuteReaderAsync(CommandBehavior.SequentialAccess))
{
  while (await reader.ReadAsync())
  {
    var data = await reader.GetTextReader(0).ReadToEndAsync();
  }
}

有了这个，同步和异步之间的差异变得难以衡量，并且改变数据包大小不再像以前那样招致荒谬的开销。

如果您希望在边缘情况下获得良好的性能，请确保使用可用的最佳工具 - 在这种情况下，流式传输大列数据，而不是依赖像 ExecuteScalar 这样的助手。或 GetFieldValue .