使用.NET简单实现一个Redis的高性能克隆版（二）

使用.NET简单实现一个Redis的高性能克隆版（二）^[1]

译者注

该原文是Ayende Rahien大佬业余自己在使用C# 和 .NET构建一个简单、高性能兼容Redis协议的数据库的经历。首先这个"Redis"是非常简单的实现，但是他在优化这个简单"Redis"路程很有趣，也能给我们在从事性能优化工作时带来一些启示。原作者：Ayende Rahien 原链接：https://ayende.com/blog/197441-A/high-performance-net-building-a-redis-clone-analysis 另外Ayende大佬是.NET开源的高性能多范式数据库RavenDB所在公司的CTO，不排除这些文章是为了以后会在RavenDB上兼容Redis协议做的尝试。大家也可以多多支持，下方给出了链接 RavenDB地址：https://github.com/ravendb/ravendb

正文

在上一篇文章中^[2]，我用最简单的方式写了一个Redis克隆版本。它能够在我们的测试实例上每秒命中近100万个查询（c6g.4xlarge，使用16个内核和64 GB内存）。在我们更深入地进行优化之前，值得了解CPU时间实际花费在哪里。我在探查器下运行服务器，以查看各种代码所耗费的成本。我喜欢使用dotTrace作为探查器，同时使用它的跟踪模式，因为它返回的数据中给了我各个模块、类和代码的执行时间以及调用次数。通常，我可以仅从这些细节中推断出很多关于系统性能的原因。看看下面的统计数据，这是连接实际处理过程中的成本细分：

img

^[3] 展开耗费CPU最多的System code，如下所示：

img

^[4]  您可以看到 FlushAsync() 方法耗费的CPU做多。我们在这里做一个假设，当我们调用 StreamWriter 的 FlushAsync() 方法时，同样会刷新底层的流。深入研究下调用栈，似乎我们在TCP层面为每个命令都都进行了分包，这样效率是很低的。如果我们将 StreamWriter 的 AutoFlush 属性改为 true ，这将导致它立即向网络流中写入数据，但不会在TCP流上调用 flush ，这会让TCP流更有效的利用缓冲空间。涉及的代码更改是删除 FlushAsync() 调用并初始化 StreamWiter ，如下所示：

using var writer = new StreamWriter(stream)
{
    NewLine = "\r\n",
    AutoFlush = true,
};

让我们再次运行基准测试，这将给我们(在我的开发机器上)：

•138,979.57 QPS [13.8w/s]– 使用 AutoFlush = true•139,653.98 QPS [13.9w/s]– 使用 FlushAsync 基本上，这两种选择都不怎么样。原因如下所示：设置为True的AutoFlush不仅会刷新当前流，还会刷新基础流，从而使Stream他们处于相同的Position。问题是我们需要刷新流，否则我们在内存中缓冲的结果数据不会发送给客户端。Redis基准测试在很大成都依赖管道(一次性发送多个命令)，但是在实际过程中可能会收到一堆来自客户端的命令，这堆命令会写入（到输入缓冲区），然后不向客户端发送任何内容，因为输出的缓冲区并没有满。我们可以使用以下代码更改轻松地优化它：

var line = await reader.ReadLineAsync();
await writer.FlushAsync();
// 修改为以下代码
var lineTask = reader.ReadLineAsync();
if(lineTask.IsCompleted == false)
{
    await writer.FlushAsync();
}
var line = await lineTask

我在这里所做的是直接写入StreamWriter，并且只有在没有更多的输入时才刷新缓冲区。这应该会大大减少包的发送次数，而且它确实做到了。再次运行基准测试可以得出以下结论：

•229,783.30 QPS [22.9w/s] – 使用延时刷新 我们只修改几行代码，却得到了几乎两倍的性能提升，这是令人影响深刻的。我们的想法是，缓冲更多的写入，并且不让它延时太久。如果写入足够的数据到StreamWriter缓冲区，它自己会自动的刷新。我们只会在没有其它需要读取的数据时手动刷新StreamWriter，这个操作是和读取并行进行的。下图是新的耗时统计：

img

^[5] 实际方法调用如下：

img

^[6]  如果我们将其与第一次分析结果进行比较，我们可以发现一些非常有趣的数字。以前，我们为每个命令调用 FlushAsync (请参阅ExecuteCommand&FlushAsync)，现在我们更少调用它了。您可以看到，现在大部分时间花费都在这个系统的“业务逻辑代码”中，从子系统的细分来看，现在很多时间都花费在处理集合中。这里的GC花费也大幅下降(~5%)。我相当确定这是因为我们使用了新的方式刷新TCP流，但我没有仔细的去检查它。请注意，虽然字符串处理和GC需要花费大量时间，但是集合/ExecuteCommand还是占用了更多的时间。如果我们调查一下，我们会发现：

img

^[7]  而且这非常有趣。主要是因为主要成本在 TryAddInternal 中。我们知道在这种情况下存在很高的争用，但92%的时间直接花在了这个方法上吗？让我们看一下代码，它在做什么就会很明显：

img

^[8]

ConcurrentDictionary对锁之间的调用进行分片。锁的数量由我们默认拥有的CPU内核数量定义。我们的的并发越多，我们就越能从增加分片数量中获益。我尝试将其设置为1024，并在分析器下运行它，这给我带来了几个百分点的改进，但并不是很多。很有价值，但不是我期望的水平。

img

^[9] 现在，我们需要找出如何在让集合操作变得更快，但我们还必须考虑总体GC成本以及字符串处理细节。在下一篇文章中会有更多关于这一点的信息。

系列链接

使用.NET简单实现一个Redis的高性能克隆版（一）^[10]

作者：InCerry

作者Github：https://github.com/incerrygit

出处：https://www.cnblogs.com/InCerry/p/Use-Dotnet-Make-A-Simple-High-Performance-Redis-2.html

版权：本作品采用「署名-非商业性使用-相同方式共享 4.0 国际^[11]」许可协议进行许可。

声明：本博客版权归「InCerry^[12]」所有。

欢迎大家关注我的微信公众号，新文章会优先发到公众号！

img

References

[1] 使用.NET简单实现一个Redis的高性能克隆版（二）: https://www.cnblogs.com/InCerry/p/Use-Dotnet-Make-A-Simple-High-Performance-Redis-2.html
[2] 上一篇文章中: https://www.cnblogs.com/InCerry/p/Use-Dotnet-Make-A-Simple-High-Performance-Redis.html
[3]

img

: https://img2022.cnblogs.com/blog/997046/202208/997046-20220804093927811-287918144.png
[4]

img

: https://img2022.cnblogs.com/blog/997046/202208/997046-20220804093927446-1067937611.png
[5]

img

: https://img2022.cnblogs.com/blog/997046/202208/997046-20220804093927095-661976682.png
[6]

img

: https://img2022.cnblogs.com/blog/997046/202208/997046-20220804093926753-688046364.png
[7]

img

: https://img2022.cnblogs.com/blog/997046/202208/997046-20220804093926367-217820360.png
[8]

img

: https://img2022.cnblogs.com/blog/997046/202208/997046-20220804093925876-270175850.png
[9]

img

: https://img2022.cnblogs.com/blog/997046/202208/997046-20220804093925103-334453984.png
[10] 使用.NET简单实现一个Redis的高性能克隆版（一）: https://www.cnblogs.com/InCerry/p/Use-Dotnet-Make-A-Simple-High-Performance-Redis.html
[11] 署名-非商业性使用-相同方式共享 4.0 国际: https://creativecommons.org/licenses/by-nc-sa/4.0/
[12] InCerry: https://incerry.cnblogs.com/