.NetCore框架Surging系列（九）性能提升-1

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

.NetCore框架Surging系列（九）性能提升

1 效果
- 1.1 测试数据-修改前
- 1.2 测试数据-修改后
- 1.3 测试方式
2 优化Swagger中间件
- 2.1 修改方式一
- 2.2 修改方式二
3 其他注意事项

在上一篇中.NetCore框架Surging系列（八）性能评估，提高Surging的吞吐量与ASP.NET Core相差较大，支持不了业务，故排查项目问题。问题之一和处理方式如下

1 效果

先看修改过的效果，修改后吞吐量至少提高1000%（十倍）

1.1 测试数据-修改前

14-1-3000策略的测试结果

Label	样本	平均值	最小值	最大值	标准偏差	异常%	吞吐量	接收 KB/sec	发送 KB/dec	平均字节数
测试Surging-Kestrel	42000	10	1	60	8.630028438	0	1259.634706	174.6759065	228.8008353	142

100-1-4000 (处理太慢-提前终止了)

Label	样本	平均值	最小值	最大值	标准偏差	异常%	吞吐量	接收 KB/sec	发送 KB/dec	平均字节数
测试Surging-Kestrel	3744	426	4	2288	306.2527968	0	225.4878343	33.03044447	44.92140448	150

1.2 测试数据-修改后

14-1-3000策略的测试结果

Label	样本	平均值	最小值	最大值	标准偏差	异常%	吞吐量	接收 KB/sec	发送 KB/dec	平均字节数
测试Surging-Kestrel	42000	2	0	36	2.2165377486679176	0.0	5332.6561706449975	781.1508062468258	2734.02782186389	150.0

100-1-3000策略的测试结果

Label	样本	平均值	最小值	最大值	标准偏差	异常%	吞吐量	接收 KB/sec	发送 KB/dec	平均字节数
测试Surging-Kestrel	300000	7	0	183	9.078329834403585	0.0	12555.453251862393	1839.1777224407801	6437.122028542731	150.0

100-1-4000策略吞吐：13488.905375328792（增幅不明显）
注销掉所有中间件：22315.2022315202

1.3 测试方式

在KestrelHttpMessageListener.csHTTP请求到达后立即返回，即在方法AppResolve中app.Run(async (context) =>之后以下代码：

private void AppResolve(IApplicationBuilder app)
{app.UseStaticFiles();app.UseMvc();_moduleProvider.Initialize(new ApplicationInitializationContext(app, _moduleProvider.Modules,_moduleProvider.VirtualPaths,AppConfig.Configuration));app.Run(async (context) =>{//测试代码 开始if (context.Request.Query.ContainsKey("httpkestrel")){var text = "httpkestrel";var data = Encoding.UTF8.GetBytes(text);var contentLength = data.Length;context.Response.Headers.Add("Content-Type", "application/json;charset=utf-8");context.Response.Headers.Add("Content-Length", contentLength.ToString());await context.Response.WriteAsync(text);return;}//测试代码 结束//...

2 优化Swagger中间件

2.1 修改方式一

工程：Surging.Core.Swagger
文件：SwaggerMiddleware.cs

修改后的部分源码

//...public class SwaggerMiddleware{private readonly RequestDelegate _next;private readonly JsonSerializer _swaggerSerializer;private readonly SwaggerOptions _options;private readonly TemplateMatcher _requestMatcher;private readonly ISwaggerProvider _swaggerProvider;public SwaggerMiddleware(RequestDelegate next,ISwaggerProvider swaggerProvider,IOptions<MvcJsonOptions> mvcJsonOptionsAccessor,IOptions<SwaggerOptions> optionsAccessor): this(next, swaggerProvider, mvcJsonOptionsAccessor, optionsAccessor.Value){ }public SwaggerMiddleware(RequestDelegate next, ISwaggerProvider swaggerProvider,IOptions<MvcJsonOptions> mvcJsonOptions,SwaggerOptions options){_next = next;_swaggerProvider = swaggerProvider;_swaggerSerializer = SwaggerSerializerFactory.Create(mvcJsonOptions);_options = options ?? new SwaggerOptions();_requestMatcher = new TemplateMatcher(TemplateParser.Parse(options.RouteTemplate), new RouteValueDictionary());}public async Task Invoke(HttpContext httpContext){//...}//...}

2.2 修改方式二

工程：Surging.Core.Swagger
文件：SwaggerGenServiceCollectionExtensions.cs

// services.AddTransient<ISwaggerProvider, SwaggerGenerator>();
//改为
services.AddSingleton<ISwaggerProvider, SwaggerGenerator>();

3 其他注意事项

ASP.NET Core 使用Swagger不会出现吞吐大幅度下降的问题；
ASP.NET Core 集成Swagger实现的源码地址为：
https://github.com/domaindrivendev/Swashbuckle.AspNetCore；
Surging的源码和上述项目源码大部分相似
第一段中的修改方式，原因未知。Surging实现方式和Swashbuckle.AspNetCore几乎相同，问题根源待论证；
第一段中的修改方式，已论证不会影响Swagger展示、调用等功能（没有测试的很细致）
网关RPC调用其他服务，相较于上篇测试效果（249）有巨幅提升，提升6-7倍
JMeter策略吞吐
13-1-3000：1373.934364
50-1-3000：1646.365613
100-1-500：1589.370291
Netty据说能够上W的处理速度，对于1千+Surging还是有很大的提升空间