线上代码压测问题梳理排查总结.docx

1、序近期在对阿里云服务器做压力测试,因为 webbench ,ab 两个工具的压力测试结果和 loadrunner,jemer 的压测结果相关太远, 有上百倍的差距 ,也是让我们百思不得其解, 非常干扰思路.所以对 ab,webbench 做了简单测试压测工具简介:工具 简介 级别Ab ab - Apache HTTP server benchmarking tool 轻量级(比 webbench 稍强大)Webbench webbench - simple forking web benchmark 轻量级jmeter Apache JMeter 是 Apache 组织开发的基于 Java 的

2、压力测试工具中级loadrunner HP 研发,收费版,但国内早破解泛滥,有 window(6G),linux(1.6G)版本重量级/专业级-loadrunner 几尽为国内测试人员的专用压测工具,他的高度灵活性 ,数据分析功能,图表展示,用户行为模拟等功能非常强大,专业压测还是以 loadrunner 为准-并发 1000 概念理解这里需再强调下并发的概念,以并发 1000 为例:这里的并发 1000 是针对用户来说,而非服务器每秒并发请求数 .即每秒有 1000 用户(每秒有多次或多种行为) 同时对服务器发起请求Webbench 每秒请求数测试-t 指定压测时间-c 指定并发用户数(非请

3、求数 )-f 零等待服务器响应如下图做了简单的性能压测.可以看出 webbench 模拟一个 client 相当于每秒有 264.8 个请求,，如果并发压-c 1000clients,相当于每秒有 1000*264.8 请求 想想也是相当凶残Ab 每秒请求数测试-n 设置请求总数-c 设置并发 client 数量如图可以看出 ab 模拟一个 client 相当于每秒有 268.04 有个请求,，如果并发压-c 1000clients,相当于每秒有 1000*268.04 请求ab/webbench 如何模拟用户行为业界一直认为 loadrunner 是最专业的,ab,webbench 相比之下

4、哪里不专业了呢,测试同学的说法是 webbench,ab 只进行了 2 次握手就离开继续下一次新请求 ,这里个人觉得不靠谱,我们模拟一次测试验证下.这里有遇到一个问题,如果去抓取一个用户数据包.ab 的功能就有大显身手了,只压一个数据包.ab -n 1 -c 1 -k http:/ 同时在被压测机抓包http 请求数据流解析抓包命令tcpdump -i eth0 ip host web-yv4 and port ! 22tcpdump -i eth0 ip host 10.169.11.99 and 10.171.215.112 and dst port 80tcpdump flagsTCP

5、Flag Flag in Flag MeaningtcpdumpSYN s Syn packet, a session establishment request. The first part of any TCP connection.ACK ack Ack packet, used to acknowledge the receipt of data from the sender. May appear in conjunction with other flags.FIN f Finish flag, used to indicate the senders intention to

6、 terminate the connection to the receiving host.RESET r Indicates the senders intention to immediately abort the existing connection.PUSH p Signals the immediate push of data from the sending host to the receiving host. For interactive applications such as telnet, the main issue is the quickest resp

7、onse time, which this “push” flag signals.URGENT urg Urgent data should take precedence over other data. For example, a Ctrl-C to terminate a FTP download.Placeholder . If the connection does not have a syn, finish, reset, or push flag set, this placefolder flag will be found after the destination p

8、ort. Note that it also appears in conjunction with the ack flag.SYN 表示建立连接，FIN 表示关闭连接，ACK 表示响应，PUSH 表示有 DATA 数据传输，RST 表示连接重置。码即 tcp 标志位，有 6 种标示：SYN(synchronous 建立联机) ACK(acknowledgement 确认) PSH(push 传送) FIN(finish 结束) RST(reset 重置) URG(urgent 紧急)Sequence number(顺序号码) Acknowledge number(确认号码)如下范例是一条完

9、整的 http 数据流分析19:28:31.951855 IP 58.246.240.122.63798 112.124.45.184.http: Flags S, seq 3672193843, win 8192, options mss 1460,nop,wscale 2,nop,nop,sackOK, length 0/client58.246.240.122 通过 63798 向 WebServer 112.124.45.184 发起一条序列号为 3672193843,win size 为 8192,没有数据的 SYNC 请求/第一次握手19:28:31.951889 IP 112.1

10、24.45.184.http 58.246.240.122.63798: Flags S., seq 38994743, ack 3672193844, win 14600, options mss 1460,nop,nop,sackOK,nop,wscale 7, length 0/WerServer 回应 ack 收到并发送一条 seq 为 38994743/第二次握手19:28:32.207276 IP 58.246.240.122.63801 112.124.45.184.http: Flags S, seq 3586463872, win 8192, options mss 1460

11、,nop,wscale 2,nop,nop,sackOK, length 0/(应该 )前两次握手失败 ,重新发起一次新一轮握手请求/第一次握手19:28:32.207304 IP 112.124.45.184.http 58.246.240.122.63801: Flags S., seq 1159592009, ack 3586463873, win 14600, options mss 1460,nop,nop,sackOK,nop,wscale 7, length 0/第二次握手19:28:32.361241 IP 58.246.240.122.63798 112.124.45.184

12、.http: Flags ., ack 1, win 16425, length 0/第三次握手 ,三次握手至此结束/client 回应收到19:28:32.361403 IP 58.246.240.122.63798 112.124.45.184.http: Flags P., seq 1:350, ack 1, win 16425, length 349/client 发起 ack 应答并 PUSH 一条长度为 349 大小数据的请求19:28:32.361419 IP 112.124.45.184.http 58.246.240.122.63798: Flags ., ack 350,

13、win 123, length 0/webserver 应答 seq 为 350 的请求 .19:28:32.361945 IP 112.124.45.184.http 58.246.240.122.63798: Flags P., seq 1:241, ack 350, win 123, length 240/webserver 应答并 PUSH 一条长度为 240 大小的数据19:28:32.383558 IP 58.246.240.122.63801 112.124.45.184.http: Flags ., ack 1, win 16425, length 0/client 应答 ac

14、k1 表示收到数据19:28:32.613585 IP 58.246.240.122.63798 112.124.45.184.http: Flags ., ack 241, win 16365, length 0/client 应答 ack241 表示收到数据19:28:37.384847 IP 58.246.240.122.63801 112.124.45.184.http: Flags F., seq 1, ack 1, win 16425, length 0/client 应答 ack1 并起一条 seq 为 1 的 FIN 断开请求/第一次挥手/tcp 状态置为 timewait 状

15、态19:28:37.384949 IP 112.124.45.184.http 58.246.240.122.63801: Flags F., seq 1, ack 2, win 115, length 0/webserver 回应收到 seq 为 1 的请求并也发起一条 seq 为 1 的 FIN 断开请求/第二次挥手/tcp 状态置为 close_wait 状态19:28:37.445546 IP 58.246.240.122.63801 112.124.45.184.http: Flags ., ack 2, win 16425, length 0/client 应答表示收到 seq 为

16、 1(这里的 ack=1 是 syn+1)的请求/第三次挥手/tcp 状态置为 closed 状态19:28:42.418048 IP 58.246.240.122.63798 112.124.45.184.http: Flags ., seq 349:350, ack 241, win 16365, length 119:28:42.418073 IP 112.124.45.184.http 58.246.240.122.63798: Flags ., ack 350, win 123, options nop,nop,sack 1 349:350, length 0/第四次挥手/serve

17、r 发起一我们具体来看下 ab/webbench 访问的过程请求,我们会发现是 webserver 先发起断开请求,loadrunner 用户行为测试Ok 至此,webbench/ab 和 loadrunner 有用户行为分析完毕,大家可能也有留意到 webserver 在这过程中断开请求的行为是不一样的.粗心的同学就会有下文的悲剧,满世界在找 webserver 端有 TIMEWAIT 的问题压测工具小结a Webbench/ab 默认使用 http1.0 协议b loadrunner 默认使用 http1.1 协议c webbench/ab 一个 client 每秒的请求数可达到 270 左右