.NET Core乱糊代码之”异步调差性能”指北

前言

故事要从好久之前说起,线上某服务从零到上线都是我撸的, 架构主要是.NET Core API + EF, 从最早的日活一千到现在日活几万.

平时在线人数几百, 高峰上千, 靠着6-8个Docker实例基本撑住了, 请求量来说QPS在100左右. 平摊下来其实每个实例的并发量不算太高.

但是某个迭代开始发现,

这个Web API有一定几率在启动的时候接收到大量请求后堆积起来, 看日志显示请求进来了, 但是一直没有到逻辑代码或者数据库查询,

所有的请求看起来都是在等调度.

已知信息

• 出现场景大多是刚启动的时候大量请求进来, 可能会把实例打崩
• 偶尔有场景是突然涌进大量用户, 也可能把实例打崩
• 发生问题时实例CPU占用率和内存都很正常, 整个宿主机运转正常, 也没有大量IO读写操作, 基本排除外部因素
• 网络情况正常, 内网中没有奇怪的数据请求,不存在网络风暴之类的东西
• 发生问题前此时数据库连接数正常, 实例不断被重启后或者一直僵死中, 数据库连接数会不断增加, 也有一定几率会把数据库连接数撑爆.

开始”侦查模式”

猜想一, 数据库搞事了?

最早怀疑是数据库连接的问题.

总所周知EF首次启动特别慢, 如果一开始查询比较多进来, 直接落到数据库查询.

每个EF实例初始化都需要耗费一定时间, 这样势必是会影响整个性能的.

这种情况下, 如果可以对EF DB Pool做一次预热是不是会好一些呢?

所以曾经在Startup.cs下面写过类似的预热代码.

private static void InitDataContextService(IApplicationBuilder app)
    Console.WriteLine($"InitDataContextService start,now:{DateTime.Now.ToString()}");
    var tasks = new List<Task>();
    for (var i = 0; i <= 10; i++)
        var serviceScope = app.ApplicationServices.CreateScope();
        var context = serviceScope.ServiceProvider.GetRequiredService<XXXContext>();
        var t = context.Database.CanConnectAsync();
        tasks.Add(t);
    Task.WaitAll(tasks.ToArray());
    Console.WriteLine($"InitDataContextService finish,now:{DateTime.Now.ToString()}");
}

用Task异步的方式来控制每次尽量产生不同的实例, 已达到预热数据量连接池的效果.

是不是很机智啊? (P, 然而并没有半毛钱的效果)

猜想二, 同步请求等待资源导致性能变差, 启动的时候被打崩?

最早版本所有的Controller Action 都是同步请求, 来一个请求同步查询数据, 执行HTTP请求等等都是正常的逻辑代码.

从来不用async/awati之类的东西.(就是这么懒)

既然出事了, 改一版看看.

开始锵锵锵改Controller Action, 改成Task的形式.

基本代码

[HttpGet("v1/books/{id}", Name = "GetBook")]
[SwaggerResponse(200, "获取成功", typeof(BookDetail))]
[SwaggerResponse(404, "找不到书籍")]
public async Task<IActionResult> GetBook([FromRoute]string id)
    return Ok(new { data = await _bookService.FindBookDetailForUser(id), code = 0 });
}

service层的用到的方法同时也改造成异步, 从头到尾都是异步.

这样测下来, 性能比同步大概涨了30%-50%左右(瞎测的, 也不太记得了数值了,没有参考意义)

就这样又上了一个版本, 比再前面几个版本都好点了, 现在发生打崩的情况降低了很多.

玄学现场:又做了一些奇怪的事情

后来又发现, 每次启动的时候, 在正式流量打入之前, 尽量预热一下api实例的话, 被直接打崩的几率会变低,

整体api会比较正常启动.

至少算是一个能操作的事情, 这个时候就很傻了, 每次发布的时候都手动ab test一下还没有转入流量的实例,

尽可能预热一下数据库和这个HTTP管道.

这个时候真的是玄学现场, 太让我沮丧了.

墨菲定律总是会来的

前天晚上发布新版本, 预发布环境政策, 性能正常之后推到生产, 然后全线告警.

神奇了, 现在又见鬼了.

用上面的压测预热折腾了一个小时, 没有成功全部启动应用, 最后无奈先回滚了, 回滚后服务正常.

OK, 这个迭代的代码加剧了应用被打崩的情况.

现总结一下当前情况

• 这次上线前, 数据库已经升级了配置, 整体监控上数据库没有任何的瓶颈
• 没有大的逻辑变动, 老的核心接口基本都异步改造完成, 新接口基本都是异步的
• 不存在缓存穿透问题, Redis缓存命中正常.

这次发布最大变更是IP定位, 需要处理headers中的IP数据,

使用ActionFilterAttribute在请求进入Action方法前完成IP到地区的转换.

这里主要会用到Redis和MaxMind.Db, 优先从Redis查询IP地区缓存, 没有命中则直接查询MaxMind.Db数据, 查询好之后再写入到Redis中.

代码大概是这样的.

public class HTTPHeaderAttribute : ActionFilterAttribute
        private readonly HTTPHeaderTools _httpHeaderTools;
        private readonly MaxMindDBClient _maxMindDBClient;
        private readonly RedisService _redisService;
        public HTTPHeaderAttribute(HTTPHeaderTools httpHeaderTools,
         MaxMindDBClient maxMindDBClient, RedisService redisService)
            _httpHeaderTools = httpHeaderTools;
            _maxMindDBClient = maxMindDBClient;
            _redisService = redisService;
        public override void OnActionExecuting(ActionExecutingContext context)
            var dicXHeaders = new Dictionary<string, string>();
            string locationISOCode = GetLocationISOCode(context);
            dicXHeaders.Add(CommonConst.LocationHeaderKey, locationISOCode);
            _httpHeaderTools.CurrentXHeaders = new ThreadLocal<Dictionary<string, string>>(() => dicXHeaders);
        private string GetLocationISOCode(ActionExecutingContext context)
            string requestIP = context.HttpContext.Request.Headers.GetHeaderValue("X-Forwarded-For");
            if(requestIP.Contains(","))
                requestIP = requestIP.Split(",")[0];
            var locationISOCode = _redisService.ReadHashValueByKey<string>(ConstRedisKey.IPLocations, requestIP);
            if (string.IsNullOrEmpty(locationISOCode))
                locationISOCode = _maxMindDBClient.GetIPLocationISOCode(requestIP);
                _redisService.WriteHash(ConstRedisKey.IPLocations, requestIP, locationISOCode);
            return locationISOCode;
    }

代码先扔着, 看起来没什么特别的地方.

好了, 我要睡了明天继续…

等我睡醒了再继续..

先直接甩真正解决问题的的代码:

public class HTTPHeaderAttribute : ActionFilterAttribute
    private readonly HTTPHeaderTools _httpHeaderTools;
    private readonly MaxMindDBClient _maxMindDBClient;
    private readonly RedisService _redisService;
    public HTTPHeaderAttribute(HTTPHeaderTools httpHeaderTools, MaxMindDBClient maxMindDBClient, RedisService redisService)
        _httpHeaderTools = httpHeaderTools;
        _maxMindDBClient = maxMindDBClient;
        _redisService = redisService;
    public override async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next)
        var dicXHeaders = new Dictionary<string, string>();
        string locationISOCode = await GetLocationISOCode(context);
        dicXHeaders.Add(CommonConst.LocationHeaderKey, locationISOCode);
        _httpHeaderTools.CurrentXHeaders = new ThreadLocal<Dictionary<string, string>>(() => dicXHeaders);
        await next();
    private async Task<string> GetLocationISOCode(ActionExecutingContext context)
        string requestIP = context.HttpContext.Request.Headers.GetHeaderValue("X-Forwarded-For");
        if (requestIP.Contains(","))
            requestIP = requestIP.Split(",")[0];
        if (string.IsNullOrEmpty(requestIP))
            return CommonConst.ChinaISOCode;
        var locationISOCode = await _redisService.ReadHashValueByKeyAsync(ConstRedisKey.IPLocations, requestIP);
        if (string.IsNullOrEmpty(locationISOCode))