.NetCore框架Surging系列（八）性能评估

.NetCore框架Surging系列（一）介绍
.NetCore框架Surging系列（二）HTTP
.NetCore框架Surging系列（三）HTTP本地路由发现过程
.NetCore框架Surging系列（四）RPC客户端过程
.NetCore框架Surging系列（五）路由注册
.NetCore框架Surging系列（六）路由发现
.NetCore框架Surging系列（七）路由监听

.NetCore框架Surging系列（八）并发评估

背景

由于项目需要满足5000+TPS，故对平台框架进行单机并发进行摸底评估。

工具

1. 客户端工具JMeter
2. Window Hyper-v 虚拟机
   CentOS 7.6
   CPU/Memory：8核/8G、16核/8G、16核/16G、32核/16G

1 结果展示

1.1 测试策略及其结果

以下为16核/16G测试情况（内存占用不高，升至32核没有太大提高）

1. 左边为架构中API请求各阶段划分（预计瓶颈点）
2. 右边为吞吐量情况
   

1.2 吞吐量

以下为14-1-3000策略的测试结果

Label	样本	平均值	最小值	最大值	标准偏差	异常%	吞吐量	接收 KB/sec	发送 KB/dec	平均字节数
测试Kestrel	42000	10	1	60	8.630028438	0	1259.634706	174.6759065	228.8008353	142
获取当前服务器时间（不通过数据库）- NOJWT - 不通RPC	42000	12	2	62	9.836624866	0	1045.790692	163.4047957	311.4903918	160
RPC-在发起传输前返回	42000	18	3	359	14.0430489	0	713.3031029	107.9706845	129.5648214	155
测试rpckestrel	42000	54	12	148	17.00182994	0	251.393137	37.07066766	49.59122428	151
测试clr	42000	76	13	246	25.12734976	0	258.6742085	36.12344903	48.24880255	143
测试http	42000	55	14	164	16.7611411	0	249.2448475	38.94450742	45.27298987	160

1.3 响应时间（平均值和90%）

平均值100ms内，90% 130ms内（运行相对稳定下值）

2 测试ASP.NET Core 3.1

    [ApiController]
    [Route("api/usertes")]
    public class WeatherForecastController : ControllerBase
    {
   
        private readonly ILogger<WeatherForecastController> _logger;

        public WeatherForecastController(ILogger<WeatherForecastController> logger)
        {
            _logger = logger;
        }

        [HttpGet("GetStaticUser")]
        public IActionResult Get()
        {
            var str = @"{'data':{'ID':'b4600fb2-61c3-4786-8ba1-9fc5387a8d17'}";
            return Ok(str);
        }
    }

以下为14-1-3000策略的测试结果

Label	样本	平均值	最小值	最大值	标准偏差	异常%	吞吐量	接收 KB/sec	发送 KB/dec	平均字节数
测试Kestrel	42000	1	0	14	0.595236373330843	0.0	5857.740585774059	3678.2492154811716	2785.859048117155	643.0

以下为1000-1-4000策略的测试结果

Label	样本	平均值	最小值	最大值	标准偏差	异常%	吞吐量	接收 KB/sec	发送 KB/dec	平均字节数
测试Kestrel	3000000	52	0	13852	141.99992902701914	0.0	15148.607842939233	9512.260588876881	7204.464862804108	643.0

3 网络测试

排除网络干扰

4 结论

1. 资源
   16核16G目前投入产出比较高
2. 并发
   JMeter策略（线程数-RampUp时间-循环次数）
   5000-1-7：线程数或循环次数加大，服务器处理过来，客户端会报错（线程超了）；
   14-1-3000：可以调节线程数和循环次数，这个策略测出吞吐量相对接近稳定运行的极限值
3. 容量预估
   目前单机吞吐以250计算，预估日活约30w，用户约140w（帕累托法则-二八定律）
4. 瓶颈点-推测

1. Kestrel中间件
2. 服务通信，RPC的寻址、并发控制、序列化、传输数据、接收数据等（Netty调优）
3. HTTP，路由映射（方法、参数等）、用户认证等

5. 相对于ASP.NETCore，Surging应该有很大优化空间