Container网络性能比较：bridge＋NAT方案与macvlan方案 (2) 性能测试结果分析

一、前言

在测试过程中，对于HLS流媒体服务，最重要的衡量量是并发用户数、延时和吞吐量。要追求的优良的性能是指能在一定数目的并发用户情况下，在应用可接受的时延内，达到一定的数据吞吐量。过多的并发用户会导致时延的指数级上升，虽然此时吞吐量未必会下降，但不是一个可以接受的结果。

在测试过程中，Spirent作为模拟客户端，跟标准的客户端player还略有不同，标准客户端在获取HLS的片段的时候，会集中一段时间拿若干片段(初始缓冲)，然后停止一下(在到达缓冲阈值前)，继续缓冲；而Spirent模拟客户端会尽力快速获取一个片段然后紧接着发出新的下一片段请求，这种方式将会最大限度的考验container的网络能力。

转载自https://blog.csdn.net/cloudvtech

二、数据流分析

bridge＋NAT方式：

1. 请求从客户端过来之后进入主机网卡
2. 在主机的网络协议栈进行NAT操作、端口转换和bridge交换
3. 从内核copy到用户进程空间，进入container内部
4. ATS进行请求处理
5. ATS根据请求内容向上游Nginx请求所需片段
6. ATS发出的请求从用户进程空间copy到内核，进入主机网络协议栈
7. 在主机的网络协议栈进行NAT操作、端口转换和bridge交换
8. 主机网卡向上游发出请求
9. Nginx返回的请求片段进入主机网卡
10. 在主机的网络协议栈进行NAT操作、端口转换和bridge交换
11. 从内核copy到用户进程空间，进入container内部
12. ATS进行处理
13. ATS向客户端发回请求的数据
14. ATS返回的数据从用户进程空间copy到内核，进入主机网络协议栈
15. 在主机的网络协议栈进行NAT操作、端口转换和bridge交换
16. 数据从主机网卡向客户端返回

macvlan方式：

1. 请求从客户端过来之后进入主机网卡
2. 在主机的网络协议栈进行基于mac地址的数据包路由选择
3. 从内核copy到用户进程空间，进入container内部
4. ATS进行请求处理
5. ATS根据请求内容向上游Nginx请求所需片段
6. ATS发出的请求从用户进程空间copy到内核，进入主机网络协议栈
7. 主机网卡向上游发出请求
8. Nginx返回的请求片段进入主机网卡
9. 在主机的网络协议栈进行基于mac地址的数据包路由选择
10. 从内核copy到用户进程空间，进入container内部
11. ATS进行处理
12. ATS向客户端发回请求的数据
13. ATS返回的数据从用户进程空间copy到内核，进入主机网络协议栈
14. 数据从主机网卡向客户端返回

在NAT方式下，一个客户端请求在主机协议栈里面上需要经历四次iptables的处理。

转载自https://blog.csdn.net/cloudvtech

三、bridge＋NAT模式的性能测试结果

2000个模拟客户端

TCP建立时延如下图

10秒HLS切片下载平均时间

网络吞吐量

转载自https://blog.csdn.net/cloudvtech

四、macvlan模式的性能测试结果

4000个模拟客户端

TCP建立时延如下图

10秒HLS切片下载平均时间

网络吞吐量

转载自https://blog.csdn.net/cloudvtech

五、性能测试结果分析

根据测试结果，macvlan模式可以在支持更多并发客户端的情况下，还具有更好的网络性能(时延和吞吐量)。

以上结果是在两种网络模式下调整模拟客户端的数目(增加和减少)所能达到的最好结果。更少的客户端时延和吞吐量很稳定，但是没有达到NIC IRQ性能瓶颈；更多的客户端，会达到NIC IRQ的性能瓶颈，引起延时和吞吐量的恶化。

注：这里的NIC IRQ瓶颈是指在本测试中使用的物理机上面的NIC由于厂商firmware的限制，只能使用最多8个逻辑CPU作为网卡驱动的软中断处理资源，这样会导致整个系统虽然还有空闲的CPU资源，但是应用程序的性能已经到了瓶颈。可以考虑升级使用支持更多CPU core作为终端处理资源的NIC来进一步提高性能：

转载自https://blog.csdn.net/cloudvtech