@whileFalse 维基百科上对于马克杯的解释是

马克杯的意思是大柄杯子，因为马克杯的英文名是“mug”，所以音译成马克杯。

你找到了盲点，这不尽管有柄但不够大，我应该称其为“茶杯” 🤔

为啥没有人提到 Microsoft.Office.Interop.Word (狗头）

我把 C#的命名习惯带去 js ，异步方法一律 Async 后缀，这样就能一眼看出

我用 Winform 缝合 Blazor （

https://learn.microsoft.com/aspnet/core/blazor/hybrid/tutorials/windows-forms?view=aspnetcore-8.0

在 C#玩 TCP 当然是 Kestrel ，微软自家出品的 Socket 封装，客户端和服务端都能用，用上它之后再也不用自己操心缓冲区了，PDU 边界（低情商俗称：粘包分包）什么的更是雕虫小技

https://learn.microsoft.com/dotnet/api/microsoft.aspnetcore.server.kestrel.transport.sockets.socketconnectioncontextfactory.create?view=aspnetcore-8.0

购物类 APP 用完就将其杀死，从未遇到过顽固推送，估计是杀死 APP 的同时通知栏内容也跟着消失吧

绿色守护免费版就够用了

XPERIA 电池保养可以设置充电电量限制在 80%或 90%, 妈妈再也不用担心我充过头了

@0o0O0o0O0o #6
米如果是几斤真空小包装,按件计
卷纸按卷计
似乎没有毛病?

@liuhan907 回来报喜
正经项目换 kestrel 重构之后，目前压测连接承载能力摸到 3 万了，需要花一点时间来 accept ，问题不大～

@liuhan907
压测了一下 Kestrel 的 TCP 服务端，花了几秒钟来 accept 两万 TCP ，虽然有部分重连，但还是全都连上了

看来以后可以用它，妈妈再也不用担心我维护不好 Socket 和 SAE 了，乐。

@liuhan907

另外，我看 Kestrel 源代码时注意到监听是单线程异步，这可能会 accept 不过来，经验告诉我如果几万 TCP 同时打进去，能进去的可能会只有几千个

https://github.com/dotnet/aspnetcore/blob/main/src/Servers/Kestrel/Transport.Sockets/src/SocketConnectionListener.cs#LL67C64-L67C64

@liuhan907 能用 ws 是我的梦想，一直在做梦，苦于设备目前只支持 TCP 接入
如果走 ws 就不需要专门开一种 TCP 服务端了，做好高可用使劲加 Web 服务器就成）

@liuhan907 #58
源代码看起来有点枯燥，倒是发现原来 core 内置的 K 服务还能处理自定义 TCP 这就有意思了，正好有个新的小规模项目可以走这条路整整😋

https://github.com/davidfowl/MultiProtocolAspNetCore/tree/master/KestrelTcpDemo

@liuhan907
那就简单来说说 (＾ o ＾)ﾉ

测试环境是 linux k8s 集群，所在节点 4 核 16G （后来加到了 8 核），非独占，还有一些其他东西跑，但不占太多 CPU

最开始的版本是图省事，嫌复杂懒得用 SocketAsyncEventArgs （ SAE ），监听开单线程阻塞，接收就用 Socket.Select 方法批量轮询，把筛出来的 Socket 滥用 Task.Run 处理接收和协议解析，可以想象线程池会有多窘迫，再多的 MinThread 也处理不过来，只会徒增 CPU 使用率。

单线程阻塞监听真是太天真了，大量 TCP 同时发起的时候根本 accept 不过来，后来改用 SAE 监听，一上来就安排 1024 个躺在端口前迎接，回调不直接处理，而是放进自己创建的工作线程排队创建应用层会话，加入会话管理器。这下几乎没有连不进去的了。

后来多几次改进调优就变成完全 SAE 了，监听和接收还有发送全都走 SAE ，只是 SAE 的回调依旧信不过，不在这里做过多的处理，而是自己开线程排队，也能观测一下队列数量来评估性能。

总算是稍微拯救了一下这难看的数据。

要问为什么自己撸 Socket 而不用现成框架，我不想回忆被 SuperSocket 折磨的那些年 _(:з)∠)_
辩解：协议单一，而且相对简单，可以自己来❌

@liuhan907
目前性能数据已经可以接受，就不放出来丢人现眼了 _(:з)∠)_

@INCerry #50
@liuhan907 #51
先谢过两位

目前用若干个绑定了队列的线程，每次有回调就挑队列长度最短的分配工作项，压测看起来数据没这么难看了
压测用 5 万个 TCP 同时打进去，PPS 没测量，几乎所有 PDU 都小于 1400 ，姑且按 PDU 计算的话，极端状况下往返加起来可能会达到（ x4 ） 20 万 PDU 每秒。
协议超时时间是 30 秒，但超过 10 秒就会被称为数据不好看

@INCerry #45
当然尝试设置最小线程数量，但收效甚微，而且 CPU 使用率显著上升

@liuhan907 #28

吾辈在 TCP 异步 Socket 高并发的情况下滥用了异步回调处理收到的数据，响应时间拉长到无法接受，排查发现是调度延迟。
后来在 SocketAsyncEventArgs 回调把要处理的东西封装成工作项，放进自己维护的线程，用线程安全队列排队处理，这才扛得起来。

这算 CPU 密集吗🤔 (不过这倒是和主题的物联网沾上边了