一个针对LVS的压力测试报告

LVS 测试报告

测试计划

1. 基本功能测试
2. 流量压力测试
3. 响应时间测试
4. 配置正确性测试
5. 灾难恢复测试

测试点

1. 基本功能测试
   • 客户端IP地址正确性
   • RealServer 访问Internet测试(包括Iptables 规则优先级)
2. 流量压力测试
   • 流量峰值测试
     • 流量达到必定值后的CPU，网卡IO，软中断状况等
   • 链接数峰值测试
     • 链接数达到必定值后，内存，CPU的状况等
3. 响应时间测试
   • 在增长LVS先后相应时间对比
4. 配置正确性测试
   • RR算法的预期值(基本功能)
   • 多配置状况下的性能
     • 添加上万条规则后，转发性能是否有影响
5. 灾难恢复测试
   • 配置导出导入测试

测试环境

• CPU Intel(R) Xeon(R) CPU E5506 @ 2.13GHz x 8
• 内存 16G
• 网卡 negotiated 1000baseT-FD
• 系统 Ubuntu 12.04
• 内核 3.5.0-23-generic

实测结果

1. 基本功能测试

客户端地址正确性

访问流程
Web Browser.Zhuhai 
113.106.x.x -> LVS(58.215.138.160) -> RS(10.20.165.174)

RS Nginx 日志以下
113.106.x.x - - [12/Feb/2015:00:18:48 +0800] "GET / HTTP/1.1" 200 612 "

结论：
验证NAT模式下客户端地址正确性为可以获取真实IP.

RealServer 访问Internet

RS 网络配置以下, gateway 为LVS的内网IP

auto eth0
iface eth0 inet static
address 10.20.165.173
gateway 10.20.165.121
netmask 255.255.255.0

在 LVS 下添加以下 iptables 规则

/sbin/iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE

实测:

zhangbo3@rise-vm-173:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=44 time=62.0 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=44 time=62.2 ms

2. 流量压力测试

高流量测试

针对一台LVS 作高流量测试，测试过程当中，并发200，20000个请求。
只针对网卡流量来看，内存，磁盘，CPU User time 不统计
每一个请求返回7MB大小的包。

压测峰值800Mb

此时的软中断

实测软中断峰值只到0.7%
此时的IN包数

此时的OUT包数

包数IN + OUT 峰值为 100K

高并发小包测试

针对一台LVS 作高并发小包测试，测试过程当中，并发80000，4KW个请求。
每一个请求返回2K大小的包。

峰值IN 流量 772Mbps 平均大概750Mbps

峰值OUT 流量 773Mbps 平均大概750Mbps

峰值IN 包数 149KPS 平均大概140KPS

峰值OUT 包数 103KPS 平均大概 90KPS

测试过程当中软中断 峰值 8.2% 平均大概 7%

测试结果:
分别测试了LVS 在大包高流量状况下和小包高并发状况下的表现。
高流量状况下，能够彻底的利用网卡性能，且无丢包和出错状况，千M网卡流量到800Mb，软中断平均在 0.7%。
高并发小包状况下，带宽为750Mbps，包流量为250KPs的状况下(已经接近网卡极限)，软中断平均在 7%.
两种状况的测试结果代表，不管是高流量仍是高并发，LVS 都可以在网卡的额定值内发挥正常。
以上测试均为对多队列网卡作软中断绑定的表现.

3. 响应时间测试

对比增长LVS先后相应时间变化

10000个并发，10W请求下

LVS 后端增长一台RealServer状况下

Concurrency Level:      10000
Time taken for tests:   13.198 seconds
Time per request:       0.132 [ms]

在未添加LVS 状况下，单独测试Realserver 数据

Concurrency Level:      10000
Time taken for tests:   14.474 seconds
Time per request:       0.145 [ms]

总结：
在增长了LVS先后，响应时间几乎没有影响.

4. 配置正确性测试

RR算法的预期值(基本功能)

分别用两台独立IP的机器对LVS作大量的长链接访问，以下为 LVS 的链接分布状况.

zhangbo3@rise-rs-135:/usr/local/nginx/conf$ sudo ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn     
TCP  58.215.x.x:80 rr
  -> 10.20.165.173:80             Masq    1      3332       14797     
  -> 10.20.165.174:80             Masq    1      3198       14931

总结:
RR算法，同一个Src IP也会定向到同一个LVS

多配置状况下的性能

初始状况下，普通配置时候，单台机器压测数据

Concurrency Level:      10000
Time taken for tests:   5.530 seconds
Complete requests:      50000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    49836
Total transferred:      42149180 bytes
HTML transferred:       30600000 bytes
Requests per second:    9040.98 [#/sec] (mean)
Time per request:       1106.074 [ms] (mean)
Time per request:       0.111 [ms] (mean, across all concurrent requests)
Transfer rate:          7442.78 [Kbytes/sec] received

向 LVS 中添加1W个端口映射后的压测数据

Concurrency Level:      10000
Time taken for tests:   5.588 seconds
Complete requests:      50000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    49974
Total transferred:      42149870 bytes
HTML transferred:       30600000 bytes
Requests per second:    8948.49 [#/sec] (mean)
Time per request:       1117.506 [ms] (mean)
Time per request:       0.112 [ms] (mean, across all concurrent requests)
Transfer rate:          7366.76 [Kbytes/sec] received

总结:
添加上网条端口映射后，对系统性能无影响.

5. 灾难恢复测试

链接状态测试

keepalived双机备份的状况下，打开LVS的链接状态后，查看同步状态发现没同步ESTABLISHED状态，SYNC_RCV，TIME_WAIT状态均已同步，握手和关闭的状态都会同步，可是ESTABLISHED的状态要发送必定的数据包才同步，默认数据包是3个，每秒50个包的频率.

配置导出导入测试

sudo ipvsadm -Sn 
可导出当前配置