c# - 使用 SqlCommand Async 方法处理大数据时性能糟糕

Question

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

我在位于我们 LAN 中的 SQL Server 2016 上创建了一个数据库(因此不是 localDB)。

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

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 ms!同样在 SQL Server Profiler 中，我看到查询执行持续时间超过一秒。尽管分析器报告的执行查询与非异步版本完全相同。

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

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 数据包大小意味着您需要大约五十个单独的 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 .