MOSN On High Performance Network

[wangfakang]

背景介绍

MOSN 在 Service Mesh 领域作为东西向 RPC 服务治理网络转发组件已经在社区很多公司都得到了一定实践，为了进一步节省研发运维等相关成本，目前业界也有很多公司在考虑把东西向和南北向数据转发面统一。MOSN 在作为东西 Sidecar 场景当前性能足以，但在作为南北向网关会有一定性能上限（比如单机百万级长连接、高并发等场景）。

解决方案（草案）

为 MOSN 在 Network 层做一个高性能的网络扩展层，使其可以和高性能网络库结合使用（如Nginx、Envoy、OpenResty 等），使其底层网络具备高性能处理的同时，又能复用 MOSN Stream Filter 等能力。

如上图所示，MOSN 通过扩展一个标准的 GOHPNF(Golang On High Performance Network Framework) 适配层和底层的高性能网络组件（如 Nginx、Envoy、Openresty 等）生态打通。使得其底层网络具备 C 同等的处理能力的同时，又能使上层业务可高效复用 MOSN 的处理能力及 GoLang 的高开发效率。

注：MOSN 和 高性能网络库是运行在一个进程空间的，高性能网络库（如 Envoy、Nginx）是通过使用 CGO 的方式来驱动 MOSN 的代码运行的，不存在跨进程通信和数据 COPY。

相关问题

• Q0 MOSN 为什么要支持底层网络库的扩展能力？

• A0 一方面是使得 MOSN 具备作为南北向数据面时需要的极致性能，另一方面可以让 MOSN 和其他高性能网络库生态（如 Nginx、Envoy、OpenResty 等）有更多的结合，在实现高性能的同时又具备了 GoLang 的开发效率。

• Q1 高性能底层网络组件是 C/C++ 实现的，后续排查问是否会困难？

• A1 底层网络扩展模块会做成一个轻量级的（成熟后基本上不用修改），另外也会完善其周边相关 Debug 调试工具。

• Q2 MOSN 在支持高性能底层网络扩展后，其 MOSN 的开发流程是否有变化？

• A2 没有变化，和之前 MOSN Stream Filter 开发流程一样。另外 MOSN 底层高性能网络扩展是可选择，用户可以根据自身业务场景选择是否开启。

• Q3 目前计划是准备使用那些高性能网络库？

• A3 还没明确，会先抽象一个 GOHPNF （GoLang On High Performance Network Framework） 适配层，然后只需在相关高性能网络库调用 GOHPNF 提供的 SDK 就可以和 MOSN 结合了。

现在，我们已经支持把 Envoy 作为一个 MOSN 的七层网络扩展，欢迎大家试用。这是相关使用文档。

动态路由事例

如下事例是通过把 MOSN 的网络扩展层设置为 Envoy 后，通过在 MOSN 侧使用 GoLang 语言开发一个 stream filter 就可以实现 Envoy 的动态路由能力：
根据用户请求 header 的 uid 字段做路由，比如将 uid 范围在 [1, 100] 的请求路由到应用的 s1 站点，将 uid 范围在 [101, 200] 的请求路由到 s2 站点，将其它范围 uid 请求路由到 s3 站点, 如果没有 uid 则将轮训转发到 s1、s2、s3。

步骤1（安装 mosn network on envoy 镜像）

docker pull mosnio/mosn-network-on-envoy:v0.20.0

步骤2（启动 mosn network on envoy 容器）

docker run -it --rm --net=host mosnio/mosn-network-on-envoy:v0.20.0

当容器正常启动后，就可以使用 curl 命令发起对应的请求，然后就可以看到上述事例路由规则的工作效果：

$curl localhost:2990 -H "uid:2"
site s1 from 3450

$curl localhost:2990 -H "uid:2"
site s1 from 3451

$curl localhost:2990 -H "uid:200"
site s2 from 3452

$curl localhost:2990 -H "uid:201"
site s3 from 3453

欢迎大家讨论和共建 ！

Background introduction

MOSN has been adopted by many companies in the community as their East-West RPC service networks data plane. To further save R&D, as well as reducing operation and maintenance overheads, many companies are considering converging their East-West and North-South data plane into one production. Currently, MOSN's performance is sufficient for East-West Sidecar scenario, yet insufficient for the North-South gateway scenario (e.g., C1000K, high concurrency, etc.).

Solution(draft)

We propose a high-performance network extension machism for MOSN, so that it can be used to combine with other high-performance network libraries (e.g. Nginx, Envoy, OpenResty, etc.). So that the network has high-performance processing and can reuse MOSN Stream Filter and other features.

As shown in the above figure, MOSN uses a standard GOHPNF (Golang On High Performance Network Framework) shim layer to connect with the underlaying high-performance network components (such as Nginx, Envoy, Openresty, etc) ecosystem. This proposal allows MOSN to increase network processing performance, while reserving Golang's high development efficiency.

Note: MOSN and the High Performance Network library run in the same process. The High Performance Network library (e.g. Envoy, Nginx) runs by calling MOSN code using CGO, and there is no cross-process communication or data COPY.

Q&A

• Q0: Why does MOSN need to support the extension of its network library?
• A0: On the one hand, it enables MOSN to obtain network performance required by a North-South data plane. On the other hand, it allows MOSN to have the ability to integrate with high-performance network library ecosystems (such as Nginx, Envoy, OpenResty, etc.) while reserving the development efficiency of GoLang.
• Q1: Is it difficult to troubleshoot since the high-performance network plugin are implemented in C/C++?
• A1: The network extension module will be made into a lightweight one (basically there is no need to modify after maturity), and the debugging tools will be improved as well.
• Q2: After MOSN supportting the plugin of high-performance network, is there any change in its MOSN development process?
• A2: No, just like the previous MOSN stream filter development process. In addition, MOSN's high-performance network extension is alternative. Users can choose their prefered network extension according to their own business scenarios.
• Q3: Which network libraries are you planning to use?
• A3: TBD, it will first abstract a GOHPNF (GoLang On High Performance Network Framework) shim layer, and then only need to call the SDK provided by GOHPNF in the high-performance network library to with MOSN.

Now, We have been supported Envoy as a Layer 7 network extension for MOSN, welcome to try it. Here is the documentation about it.

Quic start dynamic route sample

In this sample, after set Envoy as a network extension for MOSN , then Envoy's dynamic routing feature can be implemented by developing a stream filter on the MOSN side using the GoLang language.

For example, requests with uid range [1, 100] will be routed to test app site s1, requests with uid range [101, 200] will be routed to site s2, requests with other uid ranges will be routed to site s3, and if there is no uid header, the request will be round robin to s1, s2, and s3.

Step 1(Install mosn network on envoy image)

docker pull mosnio/mosn-network-on-envoy:v0.20.0

Step 2(Start mosn network on envoy container)

docker run -it --rm --net=host mosnio/mosn-network-on-envoy:v0.20.0

Then we could see the route rules at work by making a request via curl in another terminal:

$curl localhost:2990 -H "uid:2"
site s1 from 3450

$curl localhost:2990 -H "uid:2"
site s1 from 3451

$curl localhost:2990 -H "uid:200"
site s2 from 3452

$curl localhost:2990 -H "uid:201"
site s3 from 3453

Welcome to discuss and build together!

[nobodyiam]

Looks promising! 🚀🚀🚀

[junxiong]

coooool

[lemonlinger]

高性能的网络扩展层 与 Nginx，Envoy 等是怎么交互的？

[wangfakang]

高性能的网络扩展层 与 Nginx，Envoy 等是怎么交互的？

MOSN 的高性能网络扩展层和 Nginx，Envoy etc 之间是使用的 CGO 交互进行的，另外 MOSN 和 Nginx 等这些组件是在同一个进程的，减轻了夸进程的通信成本。PS： 上面的架构图已经更新了下，增加了相关请求响应的数量流向。

[wangfakang]

We propose a high-performance network extension machism for MOSN, so that it can be used to combine with other high-performance network libraries (e.g. Nginx, Envoy, OpenResty, etc.)

Lesson learned: Nginx, Envoy and OpenResty are libraries, this one could be a promising candidate too.

Yeah. We will also make this solution a standard when it is subsequently mature. This will enable more users to benefit. Welcome to build together.

[wangfakang]

@ALL Now, We have been supported Envoy as a Layer 7 network extension for MOSN, welcome to try it. Here is the documentation about it.

Quic start dynamic route sample

Install mosn network on envoy image

docker pull mosnio/mosn-network-on-envoy:v0.20.0

Start mosn network on envoy container

docker run -it --rm --net=host mosnio/mosn-network-on-envoy:v0.20.0

Test dynamic route sample

In this sample, after set Envoy as a network extension for MOSN , then Envoy's dynamic routing feature can be implemented by developing a stream filter on the MOSN side using the GoLang language.

For example, requests with uid range [1, 100] will be routed to test app site s1, requests with uid range [101, 200] will be routed to site s2, requests with other uid ranges will be routed to site s3, and if there is no uid header, the request will be round robin to s1, s2, and s3.

Then we could see the route rules at work by making a request via curl in another terminal:

$curl localhost:2990 -H "uid:2"
site s1 from 3450

$curl localhost:2990 -H "uid:2"
site s1 from 3451

$curl localhost:2990 -H "uid:200"
site s2 from 3452

$curl localhost:2990 -H "uid:201"
site s3 from 3453

[wbtlb]

golang 通过cgo具体怎么和nginx交互的,需要额外开发nginx c模块?

[wangfakang]

golang 通过cgo具体怎么和nginx交互的,需要额外开发nginx c模块?

Nginx 侧需要开发一个 filter 模块（用于引入 GoLang Network SDK，该 SDK 是暴露了和 GoLang 代码交互的 C API ）,通过在 Nginx 侧调用相关 API 封装原始请求数据后，然后把其作为输入调用相关 API 传送到 GoLang 即可运行起来。另外当前我们已经在 Envoy 侧有一个实现案例，如果感兴趣的话，你也可以参与进来适配 Nginx。

[lesismal]

高性能网络库是否考虑纯 go ？如果考虑，自荐下：
https://github.com/lesismal/nbio

0. 跨平台支持：*nix 用 epoll、kqueue, windows用的 std/net
1. epoll LT，单次读最大可配，避免饿死
2. epoll 没有使用 trigger 模式，因为较新版本的内核 epoll 相关系统调用以及其他并行流 close 都是安全的，trigger模式的无锁对性能提升也是伪命题，额外的系统调用以及内核部分的锁仍然是开销，应用层有锁并且单个 Conn 竞争几乎可以忽略，所以 trigger 模式未必有优势
3. Write是直接写，写失败才挂到Conn的队列，再添加写事件，可写、flush后清理掉写事件，尽量减少了epoll/kqueue的系统调用
4. 支持writev
5. 实现了 net.Conn，支持 DeadLine ，并发安全，也方便业务层多个并行流随意操作
6. 连接的管理，*nix直接是 fd 做数组下标对应 Conn
7. 读缓冲、应用层最大写缓冲都可配
8. 用于读取的内存分配可由应用层定制，方便业务层做更适合的定制，这个不同场景可以玩很多姿势，简单的 pool 未必是最优
9. Conn 提供 Hash 方法，方便业务层用于消息分发到指定协程进行处理，从而保证每个连接的消息处理有序
10. 单独的 heap timer，不使用 time.AfterFunc 节约协程
11. 支持管理标准库的 net.Conn

可定制、扩展的挺多的，不挨个列举了

这几天把 go 1.6 std 的 crypto/tls copy 了一份，重写了一点、支持了异步网络库的 tls server-side、server-side
标准库 tls 的 read/write buffer 确实像你们帖子里说的，看着就闹心，太不节能环保了 😂

[taoyuanyuan]

@lesismal 我们自己也是支持纯的epoll模型的，不知道和你的有什么区别，可以简单说说？
比如你是一个普通的协程来处理epoll_wait吗？ 在runtime的调度上会不会有延迟，有没有测试数据吗？

[taoyuanyuan]

再提一下我们很欢迎有纯Go的高性能网络库来加强我们的性能，正如QA所述，用户可以自由选择纯Go版本和CGO版本。 @lesismal 一些实现细节可以邮件细聊 linuxty@gmail.com

[lesismal]

再提一下我们很欢迎有纯Go的高性能网络库来加强我们的性能，正如QA所述，用户可以自由选择纯Go版本和CGO版本。 @lesismal 一些实现细节可以邮件细聊 linuxty@gmail.com

好的，邮件我先收藏了

[taoyuanyuan]

@lesismal 我们是用easygo库做的扩展，看起你这个是要高级不少，欢迎来一个pr支持你的库， 可以对比一下效果 😄

[lesismal]

@lesismal 我们是用easygo库做的扩展，看起你这个是要高级不少，欢迎来一个pr支持你的库， 可以对比一下效果

好的，我闲了先学习下MOSN，有档期了试试

[lesismal]

最近几个月魔改标准库或者从头手撸实现了异步流解析器，支持了 tls/http1.x/websocket, websocket 通过了 Autobahn Test Suite

也对 nbio 的 tls/http 1.x/websocket 内存池做了大量优化，比较费肝。
fasthttp等知名项目开了个pool的好头，但是对于异步网络库高度定制内存管理等场景，不够通用。
标准库方案的那种一个连接一个协程，就单个连接而言，在内存管理、pool定制上比异步库更方便，buffer多是在单个协程内、处理完一个消息后才会进行下一轮ReadMessage，所以内存管理更可控，异步库内存生命周期管理起来比一个连接一个协程麻烦太多了。
简单定制的tcp、固定header 也可以省力得多。
tls/http/websocket解析起来有点复杂，跨协议栈不同层之间的数据传递和cache，尤其是慢连接，比如测试解析逻辑时一个字节一个字节发送，再加上可能跨协程的buffer传递，还有解析到一个协议包后之前整段buffer的分割之后还需要粘包和cache等问题，结合2^N的pool的方案在应对慢连接时大部分性能都消耗在内存的使用上了，反倒性能不好。
最近把http/websocket的内存池改了，不再使用的2^N对齐的buffer，换成无固定长度buffer的方式了，经过最近一顿肝，基本能保证tls读写、异步流解析器、Conn写等完整流程中的内存段生命周期完善跟踪了，一个pool.Get对应一个pool.Put，但buffer被Put回去时可能大于Get出来时的cap（因为中间可能需要append），还剩一些细节地方可以优化，比如tls.Conn中的bytes.Buffer也改用pool版的、还有一些小对象也可以加入到pool管理

内存池优化后测试 10w tls websocket 连接（详情请见这个PR）

env

os: vmware ubuntu
cpu: i7 8700 4c8t
mem: 8g

test code

nbio_server
std_server
client

• cpu占用是动态的，client也是本机，server cpu load都是200-400范围波动

gorilla/websocket, 标准库方案

qps: 1-12w，平均大概6、7w，运行不稳定，stw应该会比较严重，占用

top | grep server

# output
34454 root      20   0 6221912   3.3g   1584 R 264.9  42.5   3:47.88 server

nbio

• qps: 11-12w，运行稳定，占用：

top | grep server

# output
34945 root      20   0 3883844   1.3g   6808 S 300.0  16.4   6:31.23 server 

另外，异步库性能并不是一定强于标准库，连接数较少时标准库响应可能更快，影响的点比较多，比如：

1. 标准库方案与异步库方案连接数量阈值
2. 异步解析器的实现复杂度以及streaming、half-packet时cache等消耗
3. 如果io和业务协程池分开又涉及跨协程传递的额外调度亲和性降低
4. 不同业务类型（cpu消耗和io消耗）对于整体调度的成本考量
5. 异步库使用内存池，则又涉及跨协程内存传递与生命周期管理，还有跨协议栈/层数据传递与生命周期管理，很复杂
6. 还有异步库由于不同协议栈/层与业务层之间的跨协程，导致小对象（比如Conn）难于精确释放，比如poller层面收到需要close的信号时如果释放小对象并归还到Pool，应用层此时可能仍然持有该对象，如果应用层释放前该对象又被其他地方取出，则对象脏了会出问题。并且框架层难于要求业务层去保障这个释放时机，如果要求应用层按照一定的方式使用，既难又又业务不友好，所以这些基础小对象类型Pool优化难度也大

fasthttp那种仍然是一个连接对应一个协程，它不管是小对象还是内存buffer，用池优化都相对容易，异步框架Pool优化的难度大很多

总归来讲，异步方案对于海量并发，至少协程数量的节约、内存的节约、运行的稳定性是非常明显的，连接数量达到一个阈值后可节省的调度成本也能让异步库性能优势更强

另外，easygo的性能比较一般，nbio选了一些代表性的异步库进行对比：
https://github.com/lesismal/go_network_benchmark/issues/1
https://github.com/lesismal/go_network_benchmark/issues/2

海量业务用异步库应该可以节约不少硬件成本。mosn的代码比较庞大，不敢随便PR，如果各位大佬有计划使用异步网络库替换标准库方案，欢迎使用、交流

[taoyuanyuan]

@lesismal 给老哥点赞 👍
https://github.com/cloudwego/netpoll
字节最近也开源了一个异步网络库，不知老哥有没有做对比

[lesismal]

@lesismal 给老哥点赞 👍
https://github.com/cloudwego/netpoll
字节最近也开源了一个异步网络库，不知老哥有没有做对比

之前没关注到，我去学习下，感谢推荐

[lesismal]

@lesismal 给老哥点赞 👍
https://github.com/cloudwego/netpoll
字节最近也开源了一个异步网络库，不知老哥有没有做对比

原来就是之前两个帖子里说的 KRPC 那个，应该是他们帖子里说的内核定制过的那个，如果是内核定制过的，应该性能更高，nbio可能不低于或者略好于gnet，看字节这个主页上的benchmark报告的图，他们这个比gnet还高出很多，如果benchmark数据可靠、那应该会比nbio性能更强

我抽空跑个测试看看

[lesismal]

@lesismal 给老哥点赞 👍
https://github.com/cloudwego/netpoll
字节最近也开源了一个异步网络库，不知老哥有没有做对比

参考他们文档写了个简单测试尝试了下，测试代码点我

不确定我的测试代码是否正确，上手先来10000连接跑下试试，nbio和netpoll是用的同一个虚拟机、同一个控制台，没有环境配置差异：

10000 connections

nbio

# go run ./client.go -c=10000

2021/07/16 22:40:58.975 [INF] Gopher[NB] start
2021/07/16 22:40:58 loat test for 10000 connections, buffer size: 64
2021/07/16 22:41:00 10000 clients connected, used: 1.708351955 s, 170835 ns/op
2021/07/16 22:41:00 warm up for 5s...
2021/07/16 22:41:05 warm up over, start io statistics
2021/07/16 22:41:35 30s, total read: 296.21 M, total write: 296.21 M
2021/07/16 22:41:35.790 [INF] Gopher[NB] stop

netpoll

# go run ./client.go -c=10000

2021/07/16 22:41:45.204 [INF] Gopher[NB] start
2021/07/16 22:41:45 loat test for 10000 connections, buffer size: 64

# 建立10000连接阻塞了，并且。。。死机了。。。

没办法，重启了虚拟机，然后按他们文档中的图，进行100连接数的并发测试

100 connections

nbio

# go run ./client.go -c=100

2021/07/16 22:36:55.020 [INF] Gopher[NB] start
2021/07/16 22:36:55 loat test for 100 connections, buffer size: 64
2021/07/16 22:36:55 100 clients connected, used: 0.055832512 s, 558325 ns/op
2021/07/16 22:36:55 warm up for 5s...
2021/07/16 22:37:00 warm up over, start io statistics
2021/07/16 22:37:30 30s, total read: 455.84 M, total write: 455.84 M
2021/07/16 22:37:30.080 [INF] Gopher[NB] stop

netpoll

# go run ./client.go -c=100

2021/07/16 22:40:05.398 [INF] Gopher[NB] start
2021/07/16 22:40:05 loat test for 100 connections, buffer size: 64
2021/07/16 22:40:05 100 clients connected, used: 0.077546192 s, 775461 ns/op
2021/07/16 22:40:05 warm up for 5s...
2021/07/16 22:40:10 warm up over, start io statistics
2021/07/16 22:40:41 30s, total read: 1040.48 M, total write: 1040.48 M
2021/07/16 22:40:42.031 [INF] Gopher[NB] stop

netpoll 100并发确实很猛，64 byte buffer 30s总读写量是nbio的2倍还多

然后又试了下netpoll 10000连接，再次死机。。。

他们文档中的benchmark图也只有两种：

1. echo1k（估计是payload 1k），好像没说连接数多少
2. 并发100（连接数100），好像没说payload多少

10000连接建连失败和死机的原因还不清楚，他们文档没有提供更高并发连接数的数据，文档中的benchmark repo链接也已经失效，等我闲了去issue或者学习下他们代码再看

[lesismal]

好像不只是10000连接，刚才又试了下100连接，也把我虚拟机干死了，可能因为性能过高cpu全跑满了导致死机，纳尼？。。。
但是client测试时间一共30多秒，死机了估计将近一分钟，应该是client退出后过一会系统恢复了
但是，测试开始之前我另一个终端开了top，内存占用达到 4.6 G，并且没有迅速恢复，估计是太多地方make([]byte, ...)要等go自己gc了 。nbio同样的测试内存占用是15M
给他们提了issue看看是不是我写法不对，等我闲了也研究下他们代码。。。

[lesismal]

@taoyuanyuan
上面的测试应该是我用错了接口，connection.Peek 改成 connection.Next 后正常一些了。用 Peek 时，只是拿到 buffer 结构里的内存段但没有在 buffer 结构释放该端内存，所以 buffer收到新数据时增长的更大，然后应用层读到更多、回写更多，但实际上已经是脏、不对称的回写了，因为我压测的 client 为了单机测高并发用的 nbio 异步，懒了没每次 rand data 并凑出完整包后对比数据是否一致，所以由于回写超量数据、造成了 netpoll 100 connection payload 64 性能是 nbio 2倍以上的假象

代码改为使用 connection.Next 后行为应该是正常了，但是性能只有 nbio/gnet 的一半左右，比 easygo 还慢。。。并且 netpoll 的内存占用也高太多了， nbio/gnet 做这种压测内存占用都只有十几兆到二十几兆的范围，netpoll 2-3 G，这应该是比 java 还猛了吧。
当然，仍然不排除我测试代码不正确的可能，已经提了新的 issue 等他们确认

另外发现他们的这个 connection.Next/Peed 相当于读，并且缓冲区没有足够数据时是tryRead用 chan 控制的阻塞的，这样的话。。。我又开了新的 issue 给他们： issue 13 - block read?

还有一个问题，压测10000连接，每个连接建立成功后就立刻发送数据，然后后面的建立连接非常慢，大量 SYN_SENT，盲猜一下，netpoll的listener和client的fd是有可能分配到同一个epoll fd进行管理了，如果是这样，当client的fd很忙时，listener accept的响应能力就变慢了，netpoll 的代码封装层次有点多，我没review太多，如果是盲猜的这个原因，现象就能解释通了，也给他们提了新的 issue 14 - 压测建连很慢，listener 跟 accept 得到的 fd 可能分配到相同的 epoll fd 进行管理？

issue 链接我就不引用了免得他们跑到这来了，各位大佬如果有空可以一块去瞅瞅

[zzqCh]

mosn有计划采用cloudwego的netpoll作为底层的网络库么？

[taoyuanyuan]

mosn有计划采用cloudwego的netpoll作为底层的网络库么？

目前没有计划，你们目前的痛点是啥，是目前go runtime的性能不行吗？

[zzqCh]

mosn有计划采用cloudwego的netpoll作为底层的网络库么？

目前没有计划，你们目前的痛点是啥，是目前go runtime的性能不行吗？

是的，我们压测了下，目前发现性能相比netpoll差很多，而且mosn的pprof上显示耗时最长的是gc。

[taoyuanyuan]

mosn有计划采用cloudwego的netpoll作为底层的网络库么？

目前没有计划，你们目前的痛点是啥，是目前go runtime的性能不行吗？

是的，我们压测了下，目前发现性能相比netpoll差很多，而且mosn的pprof上显示耗时最长的是gc。

你们什么场景呢，多少长连接压测？

[zzqCh]

mosn有计划采用cloudwego的netpoll作为底层的网络库么？

目前没有计划，你们目前的痛点是啥，是目前go runtime的性能不行吗？

是的，我们压测了下，目前发现性能相比netpoll差很多，而且mosn的pprof上显示耗时最长的是gc。

你们什么场景呢，多少长连接压测？

500长连接，自定义协议解析，比较耗cpu，tps基本在1.5W吧，同样的功能，在netpoll下压测可达到3.8W

[taoyuanyuan]

mosn有计划采用cloudwego的netpoll作为底层的网络库么？

目前没有计划，你们目前的痛点是啥，是目前go runtime的性能不行吗？

是的，我们压测了下，目前发现性能相比netpoll差很多，而且mosn的pprof上显示耗时最长的是gc。

你们什么场景呢，多少长连接压测？

500长连接，自定义协议解析，比较耗cpu，tps基本在1.5W吧，同样的功能，在netpoll下压测可达到3.8W

你可以分别发两个火焰图出来，我们对比看看，我理解这么点连接数，netpoll也发挥不出来优势。
我们也有一个类似netpoll的模式的，你也可以打开试试。

mosn/pkg/config/v2/server.go

Line 37 in 07be2d0

UseNetpollMode bool `json:"use_netpoll_mode,omitempty"`

[qqeasonchen]

请问这个目前已经实现了么? 有测试效果么?

[taoyuanyuan]

请问这个目前已经实现了么? 有测试效果么?

https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/golang_filter
欢迎试用提意见，已经合入envoy @qqeasonchen