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

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

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

本文测试使用的代码在：
https://github.com/JosephZhu1983/proxytest

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

测试使用的机器配置是（阿里云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

试试PooledByteBufAllocator

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

总结

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

结论是：

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