gws v1.3 update: 新增并发处理请求和异步写入特性, 不增加常驻协程

[Nazz]

Feature

• 支持并行处理请求, 控制好了并发上限
• 不增加常驻协程的情况下, 支持异步写入

实现原理(查看源码了解细节)

• 并发处理请求: 并发度为 8(可配置)的任务队列
• 异步写: 并发度为 1 的任务队列+channel

更新下压测数据

tcpkali -c 1000 --connect-rate 1000 -r 1000 -T 30s -f assets/1K.txt --ws 127.0.0.1:${port}/connect

[Nazz]

@lesismal 500 msg/s 表现和 nbio 差不多，所以我改成了 1000😆

[lesismal]

正常业务单个连接 1s 发 1000 个包早就被限流 close 了，-r 1000 比-r 500 更不合理+丧心病狂😆。。。

这种非正常压测导致 tcp 缓冲区堆积时，nbio 的异步解析器需要处理更多包边界、半包缓存，可以提高 nbio 的读缓冲区 size 来提高一点，但毕竟已经是不合理测试参数，具备这种高频的场景能想到的只有 rpc 服务，但是 rpc 服务不需要太高在线量，所以用同步方案更好、不需要基于 nbio😆

建议-r 10-50 。连接数 1000 太少了，nbio 欢迎连接数 10w 起步百万更好的压测来暴击😆

[lesismal]

不过 nbio 的内存池，在一些极端场景需要用户自己定制限量方案，比如配置单个连接的最大包 size 相关的、发送缓冲 size ，一些参数默认是 0 、是没做限制的，所以连接太多了也是可能爆，需要带上脚镣跳舞

[Nazz]

@lesismal 对比的是 nbio 阻塞模式，buffer size 我是用默认的 4096.

[Nazz]

@lesismal 百万连接不是 std net 主场了

[lesismal]

-r 这个你不考虑合理性的话，那 nbio 的异步解析器肯定吃亏的，如果非要这么卷我有点想再搞个同步解析器来兼容了😆。。。但是这除了浪费我体力没什么实际意义我不想死那么早😆。。

[Nazz]

@lesismal 别这么卷了，下次我放-r 500 ，并列第一😅