基于Netty的四层和七层代理性能方面的一些压力测试

本文咱们主要是想测试和研究几点：

• 基于Netty写的最简单的转发HTTP请求的程序，四层和七层性能的差别
• 三种代理线程模型性能的差别，下文会详细解释三种线程模型
• 池和非池化ByteBuffer性能的差别

本文测试使用的代码在： github.com/JosephZhu19…

在代码里咱们实现了两套代理程序：

测试使用的机器配置是（阿里云ECS）：

一共三台机器：

• server 服务器安装了nginx，做为后端
• client 服务器安装了wrk，做为压测客户端
• proxy 服务器安装了咱们的测试代码（代理）

Nginx后端

nginx 配置的就是默认的测试页（删了点内容，减小内网带宽）：

直接对着nginx压测下来的qps是26.6万：

有关四层和七层

四层的代理，咱们仅仅是使用Netty来转发ByteBuf。 七层的代理，会有更多额外的开销，主要是Http请求的编码解码以及Http请求的聚合，服务端：

客户端：

这里咱们能够想到，四层代理由于少了Http数据的编解码过程，性能确定比七层好不少，好多少咱们能够看看测试结果。

有关线程模型

咱们知道做为一个代理，咱们须要开启服务端从上游来获取请求，而后再做为客户端把请求转发到下游，从下游获取到响应后，返回给上游。咱们的服务端和客户端都须要Worker线程来处理IO请求，有三种作法；

• A：客户端Bootstrap和服务端ServerBootstrap独立的线程池NioEventLoopGroup，简称IndividualGroup
• B：客户端和服务端共享一套线程池，简称ReuseServerGroup
• C：客户端直接复用服务端线程EventLoop，简称ReuseServerThread

以七层代理的代码为例：

接下去的测试咱们会来测试这三种线程模型，这里想固然的猜想是方案A的性能是最好的，由于独立了线程池不相互影响，咱们接下去看看结果

四层代理 + ReuseServerThread线程模型

Layer4ProxyServer Started with config: ServerConfig(type=Layer4ProxyServer, serverIp=172.26.5.213, serverPort=8888, backendIp=172.26.5.214, backendPort=80, backendThreadModel=ReuseServerThread, receiveBuffer=10240, sendBuffer=10240, allocatorType=Unpooled, maxContentLength=2000)

四层代理 + IndividualGroup线程模型

Layer4ProxyServer Started with config: ServerConfig(type=Layer4ProxyServer, serverIp=172.26.5.213, serverPort=8888, backendIp=172.26.5.214, backendPort=80, backendThreadModel=IndividualGroup, receiveBuffer=10240, sendBuffer=10240, allocatorType=Unpooled, maxContentLength=2000)

四层代理 + ReuseServerGroup线程模型

Layer4ProxyServer Started with config: ServerConfig(type=Layer4ProxyServer, serverIp=172.26.5.213, serverPort=8888, backendIp=172.26.5.214, backendPort=80, backendThreadModel=ReuseServerGroup, receiveBuffer=10240, sendBuffer=10240, allocatorType=Unpooled, maxContentLength=2000)

看到这里其实已经有结果了，ReuseServerThread性能是最好的，其次是ReuseServerGroup，最差是IndividualGroup，和咱们猜的不一致。

四层系统监控图

从网络带宽上能够看到，先测试的ReuseServerThread跑到了最大的带宽（后面三个高峰分别表明了三次测试）：

从CPU监控上能够看到，性能最好的ReuseServerThread使用了最少的CPU资源（后面三个高峰分别表明了三次测试）：

七层代理 + ReuseServerThread线程模型

Layer7ProxyServer Started with config: ServerConfig(type=Layer7ProxyServer, serverIp=172.26.5.213, serverPort=8888, backendIp=172.26.5.214, backendPort=80, backendThreadModel=ReuseServerThread, receiveBuffer=10240, sendBuffer=10240, allocatorType=Unpooled, maxContentLength=2000)

七层代理 + IndividualGroup线程模型

Layer7ProxyServer Started with config: ServerConfig(type=Layer7ProxyServer, serverIp=172.26.5.213, serverPort=8888, backendIp=172.26.5.214, backendPort=80, backendThreadModel=IndividualGroup, receiveBuffer=10240, sendBuffer=10240, allocatorType=Unpooled, maxContentLength=2000)

七层代理 + ReuseServerGroup线程模型

Layer7ProxyServer Started with config: ServerConfig(type=Layer7ProxyServer, serverIp=172.26.5.213, serverPort=8888, backendIp=172.26.5.214, backendPort=80, backendThreadModel=ReuseServerGroup, receiveBuffer=10240, sendBuffer=10240, allocatorType=Unpooled, maxContentLength=2000)

结论同样，ReuseServerThread性能是最好的，其次是ReuseServerGroup，最差是IndividualGroup。我以为是这么一个道理：

• 复用IO线程的话，上下文切换会比较少，性能是最好的，后来我也经过pidstat观察验证了这个结论，可是当时忘记截图
• 复用线程池，客户端有机会能复用到服务端线程，避免部分上下文切换，性能中等
• 独立线程池，大量上下文切换（观察下来是复用IO线程的4x），性能最差

七层系统监控图

下面分别是网络带宽和CPU监控图：

能够看到明显七层代理消耗更多的资源，可是带宽相比四层少了一些（QPS少了不少）。 出流量比入流量多一点，应该是代码里多加的请求头致使：

试试HttpObjectAggregator设置较大maxContentLength

Layer7ProxyServer Started with config: ServerConfig(type=Layer7ProxyServer, serverIp=172.26.5.213, serverPort=8888, backendIp=172.26.5.214, backendPort=80, backendThreadModel=ReuseServerThread, receiveBuffer=10240, sendBuffer=10240, allocatorType=Pooled, maxContentLength=100000000)

试试PooledByteBufAllocator

Layer7ProxyServer Started with config: ServerConfig(type=Layer7ProxyServer, serverIp=172.26.5.213, serverPort=8888, backendIp=172.26.5.214, backendPort=80, backendThreadModel=ReuseServerThread, receiveBuffer=10240, sendBuffer=10240, allocatorType=Pooled, maxContentLength=2000)

能够看到Netty 4.1中已经把默认的分配器设置为了PooledByteBufAllocator

总结

这里总结了一个表格，性能损失比例都以第一行直接压Nginx为参照：

结论是：

• Nginx很牛，其实机器配置不算太好，在配置比较好的物理机服务器上跑的化，Nginx单机百万没问题
• Netty很牛，毕竟是Java的服务端，四层转发仅损失3% QPS
• 无论是七层仍是四层，复用线程的方式明显性能最好，占用CPU最少
• 由于上下文切换的缘由，使用Netty开发网络代理应该复用IO线程
• 七层的消耗比四层大不少，即便是Netty也避免不了，这是HTTP协议的问题
• PooledByteBufAllocator性能比UnpooledByteBufAllocator有必定提高（接近3%）
• HttpObjectAggregator若是设置较大的最大内容长度，会略微影响点性能

之因此写这个文章作这个分析的缘由是由于最近在作咱们自研网关的性能优化和压力测试 github.com/spring-aven… 。 我发现有一些其它开源的基于Netty的代理项目并非复用链接的，可能做者没有意识到这个问题，我看了下Zuul的代码，它也是复用的。