测试目标
本次测试的目标是将nginx作为7层负载均衡软件，应用于万兆环境下，获得
-
极限性能
-
在服务质量保证约束条件下的极限性能
-
提升极限性能的方法
-
在万兆环境下部署的一般方法和特殊注意事项
同时，由于nginx还作为静态页面的提供者，附带还进行获得nginx作为静态文件服务器的
-
极限性能
-
在服务质量保证约束条件下的极限性能
-
提升极限性能的方法
-
在万兆环境下部署的一般方法和特殊注意事项
操作系统是一个很大的影响因素，在测试开始，会对操作系统版本进行选择，以确定哪个是更合适的平台。
测试设备
测试设备如下
-
万兆网卡X520-DA2
-
万兆交换机DCS-7124SX-F
-
万兆DA线
-
SNB服务器
-
WSM服务器
测试环境说明
所有测试服务器连接在同一个万兆交换机下，处于同一个网段。
服务器划分为
-
服务器（以S简称）：提供静态或动态页面，次要测试对象
-
7层负载均衡（以LB简称）：提供负载均衡功能，主要测试对象
-
客户端（以C简称）：提供测试压力
特别注意事项
Keepalive
由于LB和S数量少，高RPS情况下，LB如果采用短连接方式连接S，LB的outgoing port会很快用尽。
解决的方法有两种：
-
S采用多IP配置，模拟众多S的情况，减小每个S所要消耗的LB outgoing port；
-
LB与S之间采用keepalive连接
短连接的方式下，CPU会有相当一部分消耗在三次握手上，这主要是操作系统开销（小包处理），以及nginx初始化会话上下文的开销。
RPS、PPS与流量吞吐率
极限测试下，PPS考验服务器的CPU能力；而HTTP协议请求头的处理也是CPU密集型任务。
相同流量吞吐率下
-
较小的响应意味着较高的RPS
-
当响应小于一个最大TCP报文长度时，响应越小，也意味着PPS越高
极限测试中，需要测试以下三种情形
-
全部是大报文。可以通过构造响应为一个最大TCP报文长度实现
-
全部是小报文。可以通过构造响应为最小HTTP响应实现
-
混合报文。可以通过构造响应为一个或两个TCP报文，一个是最大TCP报文长度，另外一个的长度可以控制，来满足特定的混合比例
流量吞吐率是一个表观指标，但我们更关心的是在带宽足够的条件下，RPS指标（的范围）。
压缩
在我们的实际使用中，LB是不负责压缩的。但测试中需要测试压缩对RPS的影响。需要考察压缩方面的优化方法。
规则集
负载均衡规则集大小对性能会有影响。由于规则集处理开销正比于RPS，测试中应对较大的规则集进行测试以找出影响大小和可能的优化措施。
实际网络情况
一般而言，极限性能是最理想情况。在本次测试中，我们还需要测试接近实际网络情况下的极限性能，这可以通过引入丢包率、延时来模拟。
测试项目
测试一
测试目标：了解nginx的带宽满载的最小文件大小 （web服务器模式），确定之后测试的文件大小上限
测试工具：ab
测试方法：
-
S上Nginx做简单配置，使其成为web server；
-
在C1上使用 <测试工具> 对S测试10000字节文件，每次减小1000字节，至带宽和RPS均为最高为止。
-
根据第二步测试情况调整文件大小，以逼近S的带宽恰好满载且CPU占用率最高时的情况，并记录最终的阈值大小和RPS/PPS指标。
测试结果：
| 文件大小(Bytes) | CPU idle(%) | 带宽(MBps) | PPS |
|---|---|---|---|
| 10K | 65 | 1140 | 606K |
| 3K | 12 | 1135 | 1060K |
| 2590 | 0 | 1088 | 1138K |
| 1K | 0 | 585 | 783K |
在采用kernel的pktgen发包测试中，苏能达到的最大PPS为1200K。2590Bytes文件测试中的PPS已经很接近纯发包测试的极限，所以最终，最充 分利用CPU和带宽的文件大小是2590Bytes。
测试二
测试目标：了解 nginx 的大致性能（web服务器模式）
测试工具：ab
测试方法：
-
S上Nginx做简单配置，使其成为web server；
-
在C1上使用 <测试工具> 对S分别测试空文件、616字节文件(半个包长度)、1232字节文件（即含header字节数为1448，整TCP包长度）、1 233字节文件（超过一个TCP/IP包大小1字节）和2590字节文件；3. 测试中记录S的网络吞吐量和CPU状况；C1的RPS，PPS指标波动情况。
测试预期：
-
吞吐量应超过1Gbps；
-
吞吐量接近5Gbps；
-
适当调整网卡等其他配置，应使RPS超过50万（原有百兆环境下的极限值）。
初步测试：
1、在CentOS6.2系统上，十次测试平均结果发现空文件的RPS仅为458005，响应时间0.88715ms，S带宽121M，未能达到预期。
2、检查发现CentOS6.2的ixgbe驱动版本为3.4.8，与最新版本差距较大，升级ixgbe驱动至最新版3.11.33。
更新后原先的8核client已经无法压满server，更换Client设备，ab并发由50×8提高到50×24，测试不同的InterruptThrottle Rate条件下数据如下：
1000：
1500：
2500：
3500：
4500：
根据以上数据可知，在ITR1500的情况下，空文件的RPS最高，对比数据如下：
| ITR | RPS | 带宽(MBps) | user% | sys% | irq% |
|---|---|---|---|---|---|
| 1000 | 688425 | 186.886 | 30.112 | 52.936 | 16.951 |
| 1500 | 691614 | 187.408 | 30.125 | 52.208 | 17.667 |
| 2500 | 682326 | 183.277 | 29.191 | 53.253 | 17.556 |
| 3500 | 650367 | 175.477 | 26.803 | 56.732 | 16.382 |
| 4500 | 630178 | 169.474 | 26.417 | 56.708 | 16.833 |
（注：表格中RPS和带宽数据均为峰值，CPU数据为平稳运行期的中间时刻采样值。下同）
所以在新驱动ITR1500的条件下，重新测试616,1232,1233,2590字节的数据：
616：
1232：
1233：
2590
测试过程出现剧烈的吞吐量波动，在原有的itr1500的条件下服务极不稳定。
总结ITR1500条件下各文件大小的测试数据对比如下：
| 文件大小(Btyes) | RPS | 带宽(MBps) | CPU usr% | CPU sys% | CPU irq% |
|---|---|---|---|---|---|
| 0 | 691614 | 187.408 | 30.125 | 52.208 | 17.667 |
| 616 | 586296 | 459.435 | 29.583 | 54.250 | 16.083 |
| 1232 | 579103 | 838.146 | 29.471 | 50.563 | 16.048 |
| 1233 | 513099 | 772.826 | 28.417 | 48.875 | 22.708 |
| 2590 | 418226 | 1173.760 | 23.343 | 41.934 | 18.216 |
另经测试，ITR上调到15000后，2590字节文件测试的S吞吐量恢复成稳定满带宽运行。而且支持并发到80×24。对比ITR5000/10000/15000 条件下数据：
ITR5000图
ITR10000图：
ITR15000图：
2.59KB文件在不同ITR下的测试数据对比如下：
| ITR | RPS | 带宽(MBps) | usr% | sys% | irq% | 错误进程 |
|---|---|---|---|---|---|---|
| 1500 | 418226 | 1173.760 | 23.343 | 41.934 | 18.216 | 6 |
| 5000 | 418216 | 1172.530 | 24.250 | 55.792 | 19.667 | 3 |
| 10000 | 417989 | 1171.960 | 24.625 | 52.958 | 22.292 | 2 |
| 15000 | 404330 | 1132.490 | 23.802 | 52.855 | 23.343 | 0 |
测试三
测试目标：了解nginx配置对性能的影响(access_log)
测试工具：ab
测试方法：
-
S上做简单配置，关闭 access_log 后进行测试；
-
再测试关闭 access_log buffer 的情况（对比测试二的 access_log buffer=1024k 的情况）
-
在C1上使用 <测试工具> 对S分别测试空文件(ITR为1500)
-
测试中记录CPU占用率，网络吞吐量，RPS和平均响应时间指标
测试结果：
1、设置access_log /data/access_log main;的情况：
与关闭日志相比，吞吐量下降，并且无法支持相同数并发（平均有20%的ab进程退出），只能在30×24的并发数情况下完成稳定测试。
2、将日志写入SSD磁盘，验证是否有性能提升。
由上两图对比，可见虽然将日志写入SSD对RPS稍有提升，但离关闭日志的70万差距甚远，更换SSD没有实质的意义。
3、普通磁盘上设置buffer=1024k参数
4、设置buffer=64k参数
5、设置buffer=4k参数
可见在使用buffer参数后，RPS明显提升到和关闭日志时一个数量级的水准。而buffer的大小，从4k到1024k，也可以提高10%左右。
测试三各项数据对比如下：
| 配置 | RPS | 带宽(MBps) | Usr% | Sys% | irq% | 稳定并发 |
|---|---|---|---|---|---|---|
| 关闭日志 | 691614 | 187.408 | 30.125 | 52.208 | 17.667 | 50*24 |
| 打开日志 | 180148 | 49.074 | 8.966 | 21.337 | 4.483 | 30*24 |
| 使用SSD | 144347 | 39.179 | 10.875 | 25.708 | 5.750 | 30*24 |
| buffer4K | 588767 | 159.297 | 27.613 | 55.352 | 16.951 | 50*24 |
| buffer64K | 593022 | 160.172 | 26.845 | 57.065 | 16.048 | 50*24 |
| buffer1M | 659290 | 177.959 | 32.042 | 51.875 | 16.000 | 50*24 |
测试四
测试目标：了解nginx配置对性能的影响(tcp_nopush off)
测试工具：ab
测试方法：
-
S上做简单配置，同时关闭tcp_nopush off;
-
在C1上使用 <测试工具> 对S分别测试1232字节文件和1233字节文件
-
测试中记录网络吞吐量，RPS和PPS指标
测试预期：
根据对TCP_NOPUSH的理解，在关闭此参数的情况下，1232字节文件的rps应该和开启状态下有较大差别。
测试结果：
1232字节文件数据：
当ITR为1500时：
峰值带宽比测试二中的数据稍差，但是运行不稳定，CPU的波动与rps图相对应，尝试加大并发则有client进程出现connection timeout错误。
加大itr到15000后波动变的比较稳定。但RPS下降到40万，与测试二相差接近30%。数据如下：
该项测试相关数据对比如下：
| 配置 | RPS | 带宽(MBps) | Usr% | Sys% | Irq% | 退出进程 |
|---|---|---|---|---|---|---|
| tcp_nopush on+ITR1500 | 579103 | 838.146 | 29.471 | 50.563 | 16.048 | 0 |
| tcp_nopush off+ITR1500 | 543050 | 817.746 | 27.095 | 51.438 | 21.467 | 1 |
| tcp_nopush off+ITR15000 | 393416 | 593.411 | 22.458 | 55.583 | 21.958 | 0 |
测试五
测试目标：了解nginx的大致性能（代理模式）
测试工具：ab
测试方法：
-
S上nginx做简单配置，使其成为webserver，作为后端；
-
LB上nginx做简单配置，使其成为L7 HTTP 代理，所有请求代理至S。LB后端keepalive在测试中测试两种情况，即打开和关闭
-
在C1/C2上使用 <测试工具> 对LB分别测试空文件、1232字节文件和2590字节文件
-
测试中记录S和LB的CPU占用率，网络吞吐量，RPS三个指标
测试预期：
-
Keepalive关闭时，可能需要对LB的内核参数进行调整才能够完成测试；
-
Keepalive关闭时，仅调整内核参数可能不够，S需绑定多个IP地址，LB需使用S的多个IP地址；
测试结果：
（注：因为C1/C2的主板架构/CPU配置不一。8核的C2会先于24核的C1结束测试，后半段数据不如前半段稳定，不过单C1运行也基本可以逼近LB极限，不影响 数据采集和判断。）
1、空文件：
2、1232字节文件
3、2590字节文件
4、10K字节文件
根据测试二的经验，非空文件ITR为15000时表现更稳定，修改后数据如下：
1、1232字节：
2、2590字节：
3、10k字节文件
4、100k字节文件
关闭proxy_keepalive，使用2台Client测试，并发2400。空文件测试带宽只能压到18MBps，LB和S的CPU idle都在85%以上。平均响应时间长达40ms。限于环境，压力测试无法继续进行。
本测试proxy_keepalive情况时各项数据对比如下：
| ITR+文件大小 | RPS | 带宽(MBps) | Usr% | Sys% | Irq% |
|---|---|---|---|---|---|
| ITR1500+0Byte | 392406 | 165.185 | 39.533 | 26.647 | 30.234 |
| ITR1500+1232Bytes | 369582 | 588.209 | 41.142 | 28.595 | 28.929 |
| ITR1500+2590Bytes | 296866 | 898.885 | 34.250 | 29.417 | 36.167 |
| ITR1500+10KBytes | 118163 | 1167.280 | 17.870 | 18.319 | 15.218 |
| ITR15000+1232Bytes | 370590 | 588.422 | 41.167 | 28.375 | 29.208 |
| ITR15000+2590Bytes | 297289 | 897.755 | 34.890 | 28.429 | 35.682 |
| ITR15000+10KBytes | 118033 | 1168.160 | 21.137 | 21.426 | 25.752 |
| ITR15000+100KBytes | 11388 | 1168.890 | 4.798 | 12.542 | 10.522 |
测试六
测试目标：nginx LB在多域名情况下的性能
测试工具：ab
测试方法：
1、S上nginx做简单配置，使其成为webserver，作为后端；
2、LB上nginx使用我司实际代理配置(800+域名)，使其成为L7 HTTP 代理，所有请求代理至S。LB后端keepalive在测试中测试两种情况，即打开和关闭
3、在C1上使用 <测试工具> 对LB分别测试单域名和随机多域名空文件请求
4、测试中记录S和LB的CPU占用率，网络吞吐量，RPS三个指标
测试预期：
多域名代理情况下性能应和直接通过IP访问在一个数量级内。
测试结果：
1、单域名：
2、随机域名。因为测试在2台服务器上一共开启了32个ab进程，即随机选出32个域名做的测试，结果如下：
3、关闭keepalive的情况：
可见代理模式使用多个domain和upstream配置，对性能没有太大影响。有影响的依然是keepalive是否开启。具体数据对比如下：
| 测试条件 | RPS | 带宽(MBps) | Usr% | Sys% | Irq% |
|---|---|---|---|---|---|
| IP访问 | 392406 | 165.185 | 39.533 | 26.647 | 30.234 |
| 单域名 | 377292 | 179.832 | 41.091 | 26.811 | 29.559 |
| 多域名 | 384513 | 185.632 | 43.297 | 27.186 | 28.185 |
| No keepalive | 34879 | 28.310 | 5.973 | 7.341 | 9.083 |
测试七
测试目标：其他常见server性能对比
测试工具：ab
测试方法：
Resin4pro加临时lisence，默认配置(关闭日志)，测试空文件。
测试结果：
与nginx的webserver模式对比如下：
| Webserver | RPS | 带宽(MBps) | Usr% | Sys% | Irq% |
|---|---|---|---|---|---|
| resin4 | 44873 | 32.353 | 3.884 | 4.545 | 10.455 |
| Nginx1.2 | 691614 | 187.408 | 30.125 | 52.208 | 17.667 |
术语及缩写说明
RPS: Requests per Second，每秒请求数
PPS: Packets per second，每秒报文数
附注
生成图片的 GNUplot 脚本见http://chenlinux.com/2012/11/22/gnuplot-to-draw-multi-graph。
