杂谈WebApiClient的性能优化

前言

WebApiClient的netcoreapp版本的开发已接近尾声，最后的进攻方向是性能的压榨，我把我所做性能优化的过程介绍给大家，大家可以依葫芦画瓢，应用到自己的实际项目中，提高程序的性能。

总体成果展示

使用MockResponseHandler消除真实http请求，原生HttpClient、WebApiClientCore和Refit的性能参考：

BenchmarkDotNet=v0.12.1, OS=Windows 10.0.18362.836 (1903/May2019Update/19H1)
Intel Core i3-4150 CPU 3.50GHz (Haswell), 1 CPU, 4 logical and 2 physical cores
.NET Core SDK=3.1.202
  [Host]     : .NET Core 3.1.4 (CoreCLR 4.700.20.20201, CoreFX 4.700.20.22101), X64 RyuJIT
  DefaultJob : .NET Core 3.1.4 (CoreCLR 4.700.20.20201, CoreFX 4.700.20.22101), X64 RyuJIT

Method	Mean	Error	StdDev
HttpClient_GetAsync	3.945 μs	0.2050 μs	0.5850 μs
WebApiClientCore_GetAsync	13.320 μs	0.2604 μs	0.3199 μs
Refit_GetAsync	43.503 μs	0.8489 μs	1.0426 μs

Method	Mean	Error	StdDev
HttpClient_PostAsync	4.876 μs	0.0972 μs	0.2092 μs
WebApiClientCore_PostAsync	14.018 μs	0.1829 μs	0.2246 μs
Refit_PostAsync	46.512 μs	0.7885 μs	0.7376 μs

优化之后的WebApiClientCore，性能靠近原生HttpClient，并领先于Refit。

Benchmark过程

性能基准测试可以帮助我们比较多个方法的性能，在没有性能基准测试工具的情况下，我们仅凭肉眼如何区分性能的变化。

BenchmarkDotNet是一款强力的.NET性能基准测试库，其为每个被测试的方法提供了孤立的环境，使用BenchmarkDotnet，我们很容易的编写各种性能测试方法，并可以避免许多常见的坑。

请求总时间对比

拿到BenchmarkDotNet，我就迫不及待地写了WebApiClient的老版本、原生HttpClient和WebApiClientCore三个请求对比，看看新的Core版本有没有预期的性能有所提高，以及他们与原生HttpClient有多少性能损耗。

Method	Mean	Error	StdDev
WebApiClient_GetAsync	279.479 us	22.5466 us	64.3268 us
WebApiClientCore_GetAsync	25.298 us	0.4953 us	0.7999 us
HttpClient_GetAsync	2.849 us	0.0568 us	0.1393 us
WebApiClient_PostAsync	25.942 us	0.3817 us	0.3188 us
WebApiClientCore_PostAsync	13.462 us	0.2551 us	0.6258 us
HttpClient_PostAsync	4.515 us	0.0866 us	0.0926 us

粗略地看了一下结果，我开怀一笑，Core版本比原版本性能好一倍，且接近原生。
细看让我大吃一惊，老版本的Get请求怎么这么慢，想想可能是老版本使用Json.net，之前吃过Json.net频繁创建ContractResolver性能急剧下降的亏，就算是单例ContractResolver第一次创建也很占用时间。所以改进为在对比之前，做一次请求预热，这样比较接近实际使用场景，预热之后的老版本WebApiClient，Get请求从279us降低到39us。

WebApiClientCore的Get与Post对比

从上面的数据来看，WebApiClientCore在Get请求时明显落后于其Post请求，我的接口是如下定义的：

public interface IWebApiClientCoreApi
{
    [HttpGet("/benchmarks/{id}")]
    Task GetAsyc([PathQuery]string id);

    [HttpPost("/benchmarks")]
    Task PostAsync([JsonContent] Model model);
}

Get只需要处理参数id，做为请求uri，而Post需要json序列化model为json，证明代码里面的处理参数的[PathQuery]特性性能低下,[PathQuery]依赖于UriEditor工具类，执行流程为先尝试Replace()，不成功则调用AddQUery()，UriEditor的原型如下：

class UriEditor
{ 
    public bool Replace(string name, string? value);
    public void AddQuery(string name, string? value);
}

考虑到请求uri为[HttpGet("/benchmarks/{id}")]，这里流程上是不会调用到AddQuery()方法的，所以锁定性能低的方法就是Replace()方法，接下来就是想办法改造Replace方法了，下面为改造前的Replace()实现：

/// 

/// 替换带有花括号的参数的值
/// 
/// 参数名称，不带花括号
/// 参数的值
/// 替换成功则返回true
public bool Replace(string name, string? value)
{
    if (this.Uri.OriginalString.Contains('{') == false)
    {
        return false;
    }

    var replaced = false;
    var regex = new Regex($"{{{name}}}", RegexOptions.IgnoreCase);
    var url = regex.Replace(this.Uri.OriginalString, m =>
    {
        replaced = true;
        return HttpUtility.UrlEncode(value, this.Encoding);
    });

    if (replaced == true)
    {
        this.Uri = new Uri(url);
    }
    return replaced;
}

Repace的改进方案性能对比

在上面代码中，有点经验一眼就知道是Regex拖的后腿，因为业务需要不区分大小写的字符串替换，而现成中能用的，有且仅有Regex能用了，Regex有两种使用方式，一种是创建Regex实例，一种是使用Regex的静态方法。

Regex实例与静态方法

Method	Mean	Error	StdDev
ReplaceByRegexStatic	480.9 ns	5.50 ns	5.15 ns
ReplaceByRegexNew	2,615.8 ns	41.33 ns	36.63 ns

这一跑就知道原因了，把new Regex替换为静态的Regex调用，性能马上提高5倍！

Regex静态方法与自实现Replace函数

感觉Regex静态方法的性能还不是很高，自己实现一个Replace函数对比试试，万一比Regex静态方法还更快呢。于是我花一个晚上的时间写了这个Replace函数，对，就是整整一个晚上，来为它做性能测试，为它做单元测试，为它做内存分配优化。

/// 

/// 不区分大小写替换字符串
/// 
/// 
/// 原始值
/// 新值
/// 替换后的字符中
/// 
/// 
public static bool RepaceIgnoreCase(this string str, string oldValue, string? newValue, out string replacedString)
{
    if (string.IsNullOrEmpty(str) == true)
    {
        replacedString = str;
        return false;
    }

    if (string.IsNullOrEmpty(oldValue) == true)
    {
        throw new ArgumentNullException(nameof(oldValue));
    }

    var strSpan = str.AsSpan();
    using var owner = ArrayPool.Rent(strSpan.Length);
    var strLowerSpan = owner.Array.AsSpan();
    var length = strSpan.ToLowerInvariant(strLowerSpan);
    strLowerSpan = strLowerSpan.Slice(0, length);

    var oldValueLowerSpan = oldValue.ToLowerInvariant().AsSpan();
    var newValueSpan = newValue.AsSpan();

    var replaced = false;
    using var writer = new BufferWriter(strSpan.Length);

    while (strLowerSpan.Length > 0)
    {
        var index = strLowerSpan.IndexOf(oldValueLowerSpan);
        if (index > -1)
        {
            // 左边未替换的
            var left = strSpan.Slice(0, index);
            writer.Write(left);

            // 替换的值
            writer.Write(newValueSpan);

            // 切割长度
            var sliceLength = index + oldValueLowerSpan.Length;

            // 原始值与小写值同步切割
            strSpan = strSpan.Slice(sliceLength);
            strLowerSpan = strLowerSpan.Slice(sliceLength);

            replaced = true;
        }
        else
        {
            // 替换过剩下的原始值
            if (replaced == true)
            {
                writer.Write(strSpan);
            }

            // 再也无匹配替换值，退出
            break;
        }
    }

    replacedString = replaced ? writer.GetWrittenSpan().ToString() : str;
    return replaced;
}

这代码不算长，但为它写了好多个Buffers相关类型，所以总体工作量很大。不过总算写好了，来个长一点文本的Benchmark：

public class Benchmark : IBenchmark
{
    private readonly string str = "WebApiClientCore.Benchmarks.StringReplaces.WebApiClientCore";
    private readonly string pattern = "core";
    private readonly string replacement = "CORE";

    [Benchmark]
    public void ReplaceByRegexNew()
    {
        new Regex(pattern, RegexOptions.IgnoreCase).Replace(str, replacement);           
    }

    [Benchmark]
    public void ReplaceByRegexStatic()
    {
        Regex.Replace(str, pattern, replacement, RegexOptions.IgnoreCase);
    }

    [Benchmark]
    public void ReplaceByCutomSpan()
    {
        str.RepaceIgnoreCase(pattern, replacement, out var _);
    }
}

Method	Mean	Error	StdDev	Median
ReplaceByRegexNew	3,323.7 ns	115.82 ns	326.66 ns	3,223.4 ns
ReplaceByRegexStatic	881.9 ns	16.79 ns	43.94 ns	868.3 ns
ReplaceByCutomSpan	524.0 ns	4.78 ns	4.47 ns	524.9 ns

大动干戈一个晚上，没多少提高，收支不成正比啊。

与Refit对比

在自家里和老哥哥比没意思，所以想跳出来和功能非常相似的Refit做比较看看，在比较之前，我是很有信心的。为了公平，两者都使用默认配置，都进行预热，使用相同的接口定义：

配置与预热

public abstract class BenChmark : IBenchmark
{
    protected IServiceProvider ServiceProvider { get; }

    public BenChmark()
    {
        var services = new ServiceCollection();

        services
            .AddHttpClient(typeof(HttpClient).FullName)
            .AddHttpMessageHandler(() => new MockResponseHandler());

        services
            .AddHttpApi()
            .AddHttpMessageHandler(() => new MockResponseHandler())
            .ConfigureHttpClient(c => c.BaseAddress = new Uri("http://webapiclient.com/"));

        services
            .AddRefitClient()
            .AddHttpMessageHandler(() => new MockResponseHandler())
            .ConfigureHttpClient(c => c.BaseAddress = new Uri("http://webapiclient.com/"));

        this.ServiceProvider = services.BuildServiceProvider();
        this.PreheatAsync().Wait();
    }

    private async Task PreheatAsync()
    {
        using var scope = this.ServiceProvider.CreateScope();

        var core = scope.ServiceProvider.GetService();
        var refit = scope.ServiceProvider.GetService();

        await core.GetAsyc("id");
        await core.PostAsync(new Model { });

        await refit.GetAsyc("id");
        await refit.PostAsync(new Model { });
    }
}

等同的接口定义

public interface IRefitApi
{
    [Get("/benchmarks/{id}")]
    Task GetAsyc(string id);

    [Post("/benchmarks")]
    Task PostAsync(Model model);
}

public interface IWebApiClientCoreApi
{
    [HttpGet("/benchmarks/{id}")]
    Task GetAsyc(string id);

    [HttpPost("/benchmarks")]
    Task PostAsync([JsonContent] Model model);
}

测试函数

/// 
 
/// 跳过真实的http请求环节的模拟Get请求
/// 
public class GetBenchmark : BenChmark
{ 
    /// 

    /// 使用原生HttpClient请求
    /// 
    /// 
    [Benchmark]
    public async Task HttpClient_GetAsync()
    {
        using var scope = this.ServiceProvider.CreateScope();
        var httpClient = scope.ServiceProvider.GetRequiredService().CreateClient(typeof(HttpClient).FullName);

        var id = "id";
        var request = new HttpRequestMessage(HttpMethod.Get, $"http://webapiclient.com/{id}");
        var response = await httpClient.SendAsync(request);
        var json = await response.Content.ReadAsByteArrayAsync();
        return JsonSerializer.Deserialize(json);
    }


    /// 

    /// 使用WebApiClientCore请求
    /// 
    /// 
    [Benchmark]
    public async Task WebApiClientCore_GetAsync()
    {
        using var scope = this.ServiceProvider.CreateScope();
        var banchmarkApi = scope.ServiceProvider.GetRequiredService();
        return await banchmarkApi.GetAsyc(id: "id");
    }


    /// 

    /// Refit的Get请求
    /// 
    /// 
    [Benchmark]
    public async Task Refit_GetAsync()
    {
        using var scope = this.ServiceProvider.CreateScope();
        var banchmarkApi = scope.ServiceProvider.GetRequiredService();
        return await banchmarkApi.GetAsyc(id: "id");
    }
}

测试结果

去掉物理网络请求时间段，WebApiClient的性能是Refit的3倍，我终于可以安心的睡个好觉了！

总结

这文章写得比较乱，是真实的记录我在做性能调优的过程，实际上的过程中，走过的大大小小弯路还更乱，要是写下来文章就没法看了，有需要性能调优的朋友，不防跑一跑banchmark，你会有收获的。