surging作者出具壓測結果

前言

首先回應下@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 正在往平臺化發展， 年底應該會推出社群版雛形， 望大家多多關注。