類是模板 對象是基於模板生成的實體 Car表示類，car表示變數，new關鍵字，Car()類的構造方法 Car car = new Car(); 構造方法：new欄位後跟的方法，用於創建一個對象 成員變數：類中聲明的變數稱為這個類的成員變數，類的成員變數需要對象.變數 成員方法：類中聲明的方法稱為這 ...
前言
首先回應下@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 正在往平臺化發展， 年底應該會推出社區版雛形， 望大家多多關註。
