网站建设过程中遇到的问题,东营网格通,如何做增加网站留存的营销活动,织梦程序如何搭建网站译者注该原文是Ayende Rahien大佬业余自己在使用C# 和 .NET构建一个简单、高性能兼容Redis协议的数据库的经历。首先这个Redis是非常简单的实现#xff0c;但是他在优化这个简单Redis路程很有趣#xff0c;也能给我们在从事性能优化工作时带来一些启…译者注该原文是Ayende Rahien大佬业余自己在使用C# 和 .NET构建一个简单、高性能兼容Redis协议的数据库的经历。首先这个Redis是非常简单的实现但是他在优化这个简单Redis路程很有趣也能给我们在从事性能优化工作时带来一些启示。原作者Ayende Rahien 原链接https://ayende.com/blog/197665-C/high-performance-net-building-a-redis-clone-analysis-ii另外Ayende大佬是.NET开源的高性能多范式数据库RavenDB所在公司的CTO不排除这些文章是为了以后会在RavenDB上兼容Redis协议做的尝试。大家也可以多多支持下方给出了链接RavenDB地址https://github.com/ravendb/ravendb构建Redis克隆版-第二次分析我要倒退几步看看我接下来应该看哪里看看我应该注意哪里。到目前为止在本系列中我主要关注的是如何读取和处理数据。但我认为我们应该退一两步看看我们现在的总体情况。我在分析器中运行了使用Pipelines和字符串的版本试图了解我们的进展情况。例如在上一篇文章中我使用的 ConcurrentDictionary 有很大的性能开销。现在还是这样吗以下是代码库中当前的热点数据:更详细来看如下所示可以看到处理网络请求占用了大部分的时间我们再来看看HandleConnection代码public async Task HandleConnection()
{while (true){var result await _netReader.ReadAsync();var (consumed, examined) ParseNetworkData(result);_netReader.AdvanceTo(consumed, examined);await _netWriter.FlushAsync();}
}查看代码和分析器的结果我觉得我知道如何做的更好。下面的一个小修改给我带来了2%的性能提升。public async Task HandleConnection()
{// 复用了readTask 和 flushTask// 降低了一些内存占用ValueTaskReadResult readTask _netReader.ReadAsync();ValueTaskFlushResult flushTask ValueTask.FromResult(new FlushResult());while (true){var result await readTask;await flushTask;var (consumed, examined) ParseNetworkData(result);_netReader.AdvanceTo(consumed, examined);readTask _netReader.ReadAsync();flushTask _netWriter.FlushAsync();}
}我们的想法是将网络的读写并行化。这是一个小小的提升但是任何一点点帮助都是好的特别是当各种优化会关联影响时。看看这个我们已经有将近20亿个ReadAsync调用让我们看看它的成本是多少:真是... 哇。为什么InternalTokenSource如此昂贵我敢打赌问题就在这里它被锁定了。在我的用例中我知道有一个单独的线程在运行这些命令不会有并发问题所以值得看看是否可以跳过它。不幸的是没有一个简单的方法可以跳过检查。幸运的是我可以从框架中复制代码并在本地对其进行修改以了解这样做的影响。所以我就这样做了(在构造函数中初始化一次) :这意味着我们在每次请求处理上有大约40%的改进。正如我前面提到的这不是我们现在能够做到的因为源码里面就有lock但是这是一个关于使用 PipeReader 读取数据性能损耗有趣的点。另一个非常有趣的方面是后端存储它是一个ConcurrentDictionary。如果我们看看它的成本我们会发现:您会注意到我正在使用NonBlocking的NuGet包它提供了一个无锁的 ConcurrentDictionary实现。如果我们使用.NET框架中的默认实现它确实使用了锁我们将看到下面有它们的对比:请注意这两个选项之间存在非常大的成本差别(有利于非阻塞)。但是当我们运行一个真实的基准测试时它并没有特别大的差别。那接下来呢看看分析器的结果我们没有什么可以继续改进的。我们的大部分成本都在网络中而不是在我们运行的代码中。我们的大部分代码都在 ParseNetworkData 调用中看起来像这样:所以我们实际上花在执行服务器核心功能上的时间是可以忽略不计的。实际上解析来自缓冲区的命令花费了大量时间。注意在这里我们实际上并不执行任何 I/O 操作所有操作都在内存中的缓冲区上进行操作。Redis协议对于机器解析来说并不友好需要我们进行大量的查找才能找到分隔符(因此有很多的IndexOf()调用)。我不认为你能在这方面有显著的改进。这意味着我们必须考虑其他更好的性能选择。我们花费了35% 的运行时来解析来自客户端的命令流而我们执行的代码不到运行时的1% 。我不认为流解析还有重要的优化机会因此我们只剩I/O的优化方向。我们能做得更好吗我们目前使用的是异步I/O和Pipelines。看看这个让我感兴趣的项目它在Linux使用了IO_Uring(通过这个API)来满足他们的需要。它们的解析也很简单请看这里,与我的代码运行的方式非常相似。因此为了进入性能的下一个阶段(提醒一下我们现在的性能是180w/s) 我们可能还需要使用基于IO_Uring的方法。有一个NuGet软件包来支持它但是这使得我可以在一个晚上花几个小时来完成这个任务而不是花几天或者一周的时间来完成。我不认为在不久的将来我会继续追求这个目标。结尾完结撒花按照Ayende大佬的意思是后面会尝试在linux上使用IO_Uring来实现目前来看大佬还没有其它的更新已经发布的博文已经全部翻译。我也在大佬博文底部提出了其它的一些性能优化的小建议建议来自我之前发布的文章同样高性能的网络服务开发。有兴趣的可以查看下方链接。https://www.cnblogs.com/InCerry/p/highperformance-alternats.html系列链接https://www.cnblogs.com/InCerry/p/Use-Dotnet-Make-A-Simple-High-Performance-Redis.htmlhttps://www.cnblogs.com/InCerry/p/Use-Dotnet-Make-A-Simple-High-Performance-Redis-2.htmlhttps://www.cnblogs.com/InCerry/p/Use-Dotnet-Make-A-Simple-High-Performance-Redis-3.htmlhttps://www.cnblogs.com/InCerry/p/Use-Dotnet-Make-A-Simple-High-Performance-Redis-4-and-5.htmlhttps://www.cnblogs.com/InCerry/p/Use-Dotnet-Make-A-Simple-High-Performance-Redis-6.html后续大佬有其它更新的话也欢迎艾特我催更
