V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2963 天前的主题，其中的信息可能已经有所发展或是发生改变。

我用 ab 200 个并发 60000 次请求服务器没多大压力结果如下:

Concurrency Level: 200
Time taken for tests: 14.812 seconds
Complete requests: 60000
Failed requests: 0
Total transferred: 42060000 bytes
HTML transferred: 28560000 bytes
Requests per second: 4050.64 [#/sec] (mean)
Time per request: 49.375 [ms] (mean)
Time per request: 0.247 [ms] (mean, across all concurrent requests)
Transfer rate: 2772.95 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.4 0 7
Processing: 4 47 112.2 34 3049
Waiting: 4 47 112.2 34 3049
Total: 8 47 112.2 34 3049

Percentage of the requests served within a certain time (ms)
50% 34
66% 36
75% 38
80% 40
90% 44
95% 49
98% 68
99% 1022
100% 3049 (longest request)

但是同事用 php 开了 30 个进程同时请求服务器会概率性报 502, 60000 个请求下来, 错误的请求非常多
错误日志:
2016/09/26 18:27:37 [crit] 21240#0: *1235685 connect() to 172.17.10.173:7007 failed (99: Cannot assign requested address) while connecting to upstream, client: 172.17.10.173, server: 172.17.10.173

看了 nginx 的访问日志, ab 测试的时候每秒请求达到 4 千多次

但是同事的请求每秒才三千多为啥同事的请求会有很多失败的呢? 谁能解答一下疑惑吗不胜感激了

第 1 条附言 · 2016-09-26 20:10:36 +08:00

就这么简单的开20个进程来刷都会报错....用ab跑400个并发都没啥是不是ab的并发是假的啊...

python

# coding: utf8

import requests
if __name__ == '__main__':
import sys
argv = sys.argv
c = argv[1]
for i in range(int(c)):
    req = requests.get('http://172.17.10.173:7000/user/profile/?user_id=50')
    print req.json()

bash脚本

#!/bin/bash

for((i=0; i<20; i++));
    do

        echo $i
        python t.py 3000 &

done;

第 2 条附言 · 2016-09-26 21:02:49 +08:00

以上 python 脚本会导致服务器停止响应的问题应该是过多的请求导致了过多的 tcp time_wait 状态导致以后的请求无法绑定端口然后就报错了....

实际看服务器上的 time_wait 也确实非常多

用 ab 测试就不会有这个问题最多的 time_wait 也就一万多...

不知道为啥会这样, 估计是 ab 对并发请求做了优化吧

第 3 条附言 · 2016-09-26 21:12:53 +08:00

好吧我想我知道原因了

是客户端的 TIME_WAIT 过多导致客户端无法建立连接了是自己把自己刷死了跟服务器没关系....
23333

第 4 条附言 · 2016-09-27 18:53:40 +08:00

总结一下吧

ab的并发测试没问题
只是我们在多次查询的时候的写法有问题, 导致了客户端产生过多的time-wait状态进而影响了新连接的建立, 最终的情况就是客户端建立不了连接无法请求
关于time-wait, 根据tcp的断开的四次握手, 主动断开方会产生time-wait的状态并保持两个msl(60秒)时间, 从而占用连接资源
客户端多次请求服务端的时候, 由于每次都是新建连接(没有复用之前的连接) 而且头部默认 Connection:keep-alive, 从而导致了主动断开连接的一方是客户端, 当请求过多(20*3000)的时候, 客户端会产生大量的time-wait, 然后就没有然后了. 这个解决方法很简单, 设置每次请求的 conneciton为close, 把关闭连接提交给服务端, 但是这样会导致服务端产生大量的time-wait从而影响服务端. 所以最终的解决方案两个端都要做相应的处理
客户端: 多次请求复用连接, 设置keep-alive, 比如python的话可以用 requests.session() 新建一个会话, 每次使用该会话进行请求, 测试表明, 这种情况下不会产生过多的time-wait
服务端: 更改tcp的系统参数: (以下设置表明不重用tw的连接, 但是打开系统快速回收tw)
```
  sysctl -w net.ipv4.tcp_tw_reuse=0
  sysctl -w net.ipv4.tcp_tw_recycle=1
  sysctl -w net.ipv4.tcp_timestamps=1
```
添加了这几个配置之后, 可以明显的看到服务端的tw状态连接数不会过大, 维持在一个可以接受的范围了.

参考:

http://huoding.com/2013/12/31/316
http://www.qmailer.net/archives/92.html
http://www.cnblogs.com/yjf512/p/5327886.html

Requests

172.17.10.173

请求

mean

15 条回复 • 2016-10-20 23:11:03 +08:00

Citrus

2016-09-26 18:48:43 +08:00

99: Cannot assign requested address
目测是你变量没控制好，有其它程序干扰；或者你同事是在 Nginx 同一台机器上压同一台，导致连接数超了。

Nexvar

2016-09-26 18:55:00 +08:00 via Android

用 php 开 30 多个进城。。。
AB 的优点就在用少量线程实现多连接多请求

geew

2016-09-26 18:55:40 +08:00

@Citrus 30 个进程不是 30 个并发吗? 他在他机子上用 ab 测试的结果跟我的差不多但是本机跑 30 个进程来刷就会有问题环境问题的可能性比较小

geew

2016-09-26 18:56:53 +08:00

@Nexvar 我不了解 php 但是他的需求是需要在一定时间内查询多个东西所以才会用多个进程来进行处理的貌似 php 没有线程吧

Citrus

2016-09-26 19:00:22 +08:00

@geew 首先明确几个问题：
1. 你的 ab 测试时和 Nginx 是否是同一台机器
2. PHP 测试时，是否和 Nginx 同一台机器
3. Nginx 的 KeepAlive 设置的是多少
4. 系统的 TCP KeepAlive 是多少
5. 测试间隔是多少
6. 测试期间是否确认绝对没有其他人再使用这台机器，包括定时任务等可能你没注意到的东西

geew

2016-09-26 19:26:39 +08:00

@Citrus
1. 不是同一台机器, 同一个内网
2. 同 1, 他在他机子上用 ab 测试结果跟我用 ab 测试差距不大
3. 没有特别设置, 默认值吧, 话说默认值多少....
4. 也没用特别设置
5. 间隔几分钟吧
6. 这个没法保证, 但是 php 跑进程测试和 ab 测试的环境基本都是一致的

Citrus

2016-09-26 20:34:13 +08:00

@geew ab 的完整命令发一下？ url 请打码。

geew

2016-09-26 20:40:13 +08:00

@Citrus 哈哈没事内网的 url
ab -n 60000 -c 200 http://172.17.x.y:8888/user/profile/?user_id=50

halfcrazy

2016-09-26 21:05:55 +08:00 via Android

@geew ab 加上-k 试试

geew

2016-09-26 21:13:23 +08:00

@halfcrazy 哈哈谢谢你看我最后几条附言

geew

2016-09-26 21:21:20 +08:00

@halfcrazy 但是 ab 测试的时候服务端会产生很多的 TIME_WAIT 但也不是问题

netstat -ant | grep "TIME_WAIT" | wc -l
63873

为啥客户端 TIME_WAIT 一到两万多就开始崩了

ovear

2016-09-26 21:31:20 +08:00

@geew ....额。。你用 http1.1 测试试。。不然端口不够是这样的。。

Citrus

2016-09-26 22:05:26 +08:00

@geew 从一开始就猜到是你 TIME_WAIT 的原因。。。不过没想到是你客户端撑不住。 ulimit 看看限制。

geew

2016-09-27 10:03:51 +08:00

@Citrus 看哪个
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 63603
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 63603
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

这是我的电脑它当客户端的时候 TIME_WAIT 达到三万那样子就不行了但是当服务端 TIME_WAIT 达到六万多都没啥...

geew

2016-10-20 23:11:03 +08:00

@geew

有关 ab 压力测试的一个奇怪的现象

python

bash脚本