前言
首先回應下@wen-wen 所貼的壓測報告,我也把我和客戶壓測碰到的問題,和壓測結果貼出來,這個結果是由客戶提供的。不會有任何的舞弊手腳問題
問題一:Task.Run慎用
首先在最新的社群版本已經把Task.run全部去掉了(包括了kestrel RPC呼叫服務),當你的程式有比較耗時的業務處理的時候,Task可以提升效能,但是不耗時的時候,也許就不能提高效能,反而成為瓶頸,因為當一批Task.run未執行完,新一批的請求又來了,就會阻塞造成cpu的升高,所以之前在netty 的ServerHandler中使用task.run ,在壓測不帶業務的服務時候,因為都是納秒級的響應,所以造成了task的阻塞,執行萬次的迴圈壓測,CPU一直在20%左右,後續已經通過netty 的業務執行緒進行處理,CPU一直穩定在6%左右, 程式碼如下
if (_logger.IsEnabled(LogLevel.Debug)) _logger.LogDebug($"準備啟動服務主機,監聽地址:{endPoint}。"); IEventLoopGroup bossGroup = new MultithreadEventLoopGroup(1); IEventLoopGroup workerGroup = new MultithreadEventLoopGroup();//Default eventLoopCount is Environment.ProcessorCount * 2 var bootstrap = new ServerBootstrap(); if (AppConfig.ServerOptions.Libuv) { var dispatcher = new DispatcherEventLoopGroup(); bossGroup = dispatcher; workerGroup = new WorkerEventLoopGroup(dispatcher); bootstrap.Channel<TcpServerChannel>(); } else { bossGroup = new MultithreadEventLoopGroup(1); workerGroup = new MultithreadEventLoopGroup(); bootstrap.Channel<TcpServerSocketChannel>(); } var workerGroup1 = new SingleThreadEventLoop();// 宣告業務執行緒 bootstrap .Option(ChannelOption.SoBacklog, AppConfig.ServerOptions.SoBacklog) .ChildOption(ChannelOption.Allocator, PooledByteBufferAllocator.Default) .Group(bossGroup, workerGroup) .ChildHandler(new ActionChannelInitializer<IChannel>(channel => { var pipeline = channel.Pipeline; pipeline.AddLast(new LengthFieldPrepender(4)); pipeline.AddLast(new LengthFieldBasedFrameDecoder(int.MaxValue, 0, 4, 0, 4)); pipeline.AddLast(workerGroup1, "HandlerAdapter", new TransportMessageChannelHandlerAdapter(_transportMessageDecoder));//新增業務執行緒處理 //新增業務執行緒處理
pipeline.AddLast(workerGroup1, "ServerHandler", new ServerHandler(async (contenxt, message) => { var sender = new DotNettyServerMessageSender(_transportMessageEncoder, contenxt); await OnReceived(sender, message); }, _logger)); })); try { _channel = await bootstrap.BindAsync(endPoint); if (_logger.IsEnabled(LogLevel.Debug)) _logger.LogDebug($"服務主機啟動成功,監聽地址:{endPoint}。"); } catch { _logger.LogError($"服務主機啟動失敗,監聽地址:{endPoint}。 ");
}
}
問題二:檢查主頻,核數
首先客戶一開始測試使用的是家庭電腦,他一直壓測不上去,說用jmeter怎麼2000就timeout了,後面瞭解到他的電腦是4核,主頻1.8,記憶體32G,後面告訴他你要達到預期就要高頻或者多核的乾淨電腦。
問題三:檢查熔斷策略
檢查MaxConcurrentRequests,ExecutionTimeoutInMilliseconds 等設定
客戶結果
單表新增資料庫, cpu 一直保持在30%,可能因為ingress設定關係只能壓測到4000
個人測試結果
無業務壓測:
用httpkestrel 壓測可以達到2w/s, rpc 可以達到10w/s
rpc 大家都可以測試, 通過社群版本下載, 啟用server, 開啟多個client 進行壓測,有問題可以告訴我
總結
surging 正在往平臺化發展, 年底應該會推出社群版雛形, 望大家多多關注。