netcore日志框架对比,netcore并发性能优化

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

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

MMP现在广告遮住右边的菜单栏了 .NetCore框架Surging系列（八）并发评估背景工具1 结果展示1.1 测试策略及其结果1.2 吞吐量1.3 响应时间（平均值和90%） 2 测试ASP.NET Core 3.13 网络测试4 结论

背景

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

工具 客户端工具JMeterWindow Hyper-v 虚拟机
CentOS 7.6
CPU/Memory：8核/8G、16核/8G、16核/16G、32核/16G 1 结果展示 1.1 测试策略及其结果

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

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

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

Label样本平均值最小值最大值标准偏差异常%吞吐量接收 KB/sec发送 KB/dec平均字节数测试Kestrel42000101608.63002843801259.634706174.6759065228.8008353142获取当前服务器时间（不通过数据库）- NOJWT - 不通RPC42000122629.83662486601045.790692163.4047957311.4903918160RPC-在发起传输前返回4200018335914.04304890713.3031029107.9706845129.5648214155测试rpckestrel42000541214817.001829940251.39313737.0706676649.59122428151测试clr42000761324625.127349760258.674208536.1234490348.24880255143测试http42000551416416.76114110249.244847538.9445074245.272989871601.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平均字节数测试Kestrel4200010140.5952363733308430.05857.7405857740593678.24921548117162785.859048117155643.0

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

Label样本平均值最小值最大值标准偏差异常%吞吐量接收 KB/sec发送 KB/dec平均字节数测试Kestrel300000052013852141.999929027019140.015148.6078429392339512.2605888768817204.464862804108643.0

3 网络测试

排除网络干扰

4 结论 资源
16核16G目前投入产出比较高并发
JMeter策略（线程数-RampUp时间-循环次数）
5000-1-7：线程数或循环次数加大，服务器处理过来，客户端会报错（线程超了）；
14-1-3000：可以调节线程数和循环次数，这个策略测出吞吐量相对接近稳定运行的极限值容量预估
目前单机吞吐以250计算，预估日活约30w，用户约140w（微笑的万宝路法则-二八定律）瓶颈点-推测 Kestrel中间件服务通信，RPC的寻址、并发控制、序列化、传输数据、接收数据等（Netty调优）HTTP，路由映射（方法、参数等）、用户认证等 相对于ASP.NETCore，Surging应该有很大优化空间