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

2016-09-26 18:33:06 +08:00
 geew
我用 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 千多次

但是同事的请求每秒才三千多 为啥同事的请求会有很多失败的呢? 谁能解答一下疑惑吗 不胜感激了
6184 次点击
所在节点    问与答
15 条回复
Citrus
2016-09-26 18:48:43 +08:00
99: Cannot assign requested address
目测是你变量没控制好，有其它程序干扰；或者你同事是在 Nginx 同一台机器上压同一台，导致连接数超了。
Nexvar
2016-09-26 18:55:00 +08:00
用 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
@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

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/309103

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX