使用带有大数据的 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 中，我看到查询执行持续时间超过一秒。虽然 profiler 报告的执行查询与非 Async 版本完全相同。

但情况会变得更糟。如果我在连接字符串中使用 Packet Size，我会得到以下结果：

数据包大小 32768 : [TIMING]: SqlValueStore 中的 ExecuteScalarAsync -> 经过时间：450 毫秒

数据包大小 4096 : [TIMING]: SqlValueStore 中的 ExecuteScalarAsync -> 经过时间：3667 毫秒

数据包大小 512 : [TIMING]: SqlValueStore 中的 ExecuteScalarAsync -> 经过时间：30776 毫秒

30,000 毫秒！！这比非异步版本慢 1000 倍以上。 SQL Server Profiler 报告查询执行耗时超过 10 秒。这甚至无法解释其他 20 秒的去向！

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

作为旁注，如果它只将一个小字符串（

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

Answer 1

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

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

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

因此我们可以看到问题在于单个行和/或列的大小过大。总共有多少数据并不重要 - 异步读取一百万个小行与同步读取一样快。但是只添加一个太大而无法放入单个数据包的字段，并且您在异步读取该数据时神秘地产生了成本 - 好像每个数据包都需要一个单独的请求数据包，而服务器不能只发送所有数据一次。使用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 这样的帮助程序。