如何构造具有在线效果的无限压力(试验采用的tcpcopy为0.5以下的老版本)

来源:互联网 发布:caffe dropout 编辑:程序博客网 时间:2024/05/01 14:13

我们做一个实验,在这个实验中,我们有四台机器,208,217,148,161,其中208和217在北京,148和161在杭州。

我们在208中利用压力测试工具发起压力请求到217中去,在217上利用tcpcopy把请求复制到148中去,再在148复制请求到161中去。

我们先准备准备:

161上,我们设置如下:

[root@bgp176_161 bin]# iptables -I OUTPUT -p tcp --sport 8080 -j QUEUE      (ip queue模块之前已经启动)
[root@bgp176_161 bin]# ./interception 


148上,我们设置如下:

[root@bgp176-148 ~]# iptables -I OUTPUT -p tcp --sport 8080 -j QUEUE
[root@bgp176-148 bin]# ./interception

[root@bgp176-148 bin]# ./tcpcopy xxx.xxx.xxx.148 8080 xxx.xxx.xxx.161 8080
I am booted


217上,我们设置如下:

[root@tuan tcpcopy]# ./tcpcopy xxx.xxx.xxx.217 18081 xxx.xxx.xxx.148 8080   
I am booted

(217 resin开启18081端口)


208运行命令如下:

[wangbin@yz250-208 tmp]$  ./httpsender -c 1 -n 3000 -r 0 -H "Connection:Close" -H "Host:test.163.com" http://xxx.xxx.xxx.217:18081/xxx.jsp


217,148,161启动resin服务器,各台服务器都会访问同一台数据库,我们的目的就是构造无限在线请求压力测试db(这里机器有限,所以请求也是有限)


运行后效果如下:

148上面的resin日志

[wangbin@bgp176-148 logs]$ wc -l access.log
3000 access.log

161上面的resin日志:

[wangbin@bgp176_161 logs]$ wc -l access.log
3000 access.log


从上面我们可以看出,从217复制的请求都到148上面去了,148上面的请求也同样被复制到161上面去了.

由于请求都到了相应的resin服务器,这些请求都会访问db,造成db的压力增加到原来的3倍,效果会和实际效果差不太多,唯一缺陷是同一个请求会被调用三次,这点不是很真实,但这是从不同的服务器过来的,总比ab等压力测试工具真实地多.


我们对某系统实战一下

141是在线服务器,真实的

[root@bgp176-141 work]# ./tcpcopy xxx.xxx.xxx.137:xxx.xxx.xxx.140 80 xxx.xxx.xxx.148 18080
I am booted

复制请求到148中去

[root@bgp176-148 bin]# ./interception

[root@bgp176-148 bin]# ./tcpcopy xxx.xxx.xxx.148 18080 xxx.xxx.xxx.161 18080
I am booted

复制请求到161中去

[root@bgp176_161 bin]# ./interception 


其中148和161的nginx服务器会随着情况访问148后面的应用服务器


[wangbin@bgp176-141 logs]$ ps aux|grep tcpcopy                            
root     28094 36.8  0.6  39136 26208 pts/0    Sl+  10:11   1:08 ./tcpcopy xxx.xxx.xxx.137:xxx.xxx.xxx.140 80 xxx.xxx.xxx.148 18080
wangbin  28205  0.0  0.0  61188   732 pts/1    S+   10:14   0:00 grep tcpcopy

我们可以看到10:11分开始从在线服务器141复制请求到148上面去的.


148上面nginx的日志情况如下:

[wangbin@bgp176-148 logs]$ tail -n 1000000 access.log |grep '11/Nov/2011:10:15'|wc -l
117586

148上面的应用服务器压力如下:

[wangbin@bgp176-148 logs]$ grep 'Fri 10:15:' access_1111_10.log |wc -l      
41837


我们复制148的请求到161中去

[wangbin@bgp176-148 logs]$ ps aux|grep tcpcopy
root      9667 41.0  1.1  36500 23560 pts/1    Rl+  10:18   0:20 ./tcpcopy xxx.xxx.xxx.148 18080 xxx.xxx.xxx.161 18080
wangbin   9670  0.0  0.0   4000   692 pts/2    S+   10:19   0:00 grep tcpcopy

我们可以看到10:18分开始从测试服务器148复制请求到测试服务器161上面去的.


10:21分

在线服务器141上面的nginx负载如下:

[wangbin@bgp176-141 logs]$ tail -n 1200000 access.log |grep '2011:10:21' |wc -l  
115295


测试服务器148上面的nginx负载如下:

[wangbin@bgp176-148 logs]$ tail -n 1000000 access.log |grep '11/Nov/2011:10:21'|wc -l  
115237


测试服务器161上面的nginx负载如下:

[wangbin@bgp176_161 logs]$ tail -n 1000000 access.log |grep '11/Nov/2011:10:21'|wc -l  
114535


测试服务器148上面的应用服务器负载如下:

[wangbin@bgp176-148 logs]$ grep 'Fri 10:21:' access_1111_10.log |wc -l  
81269

我们可以看出148上面的应用服务器负载比之前增加了一倍左右.


如果你想增加压力,利用级联tcpcopy,会是一个不错的选择