尝试在ab的非工作时间重现这种行为,当超过大约256个用户时,我发现性能大幅下降.使用尽可能小的用例运行测试我可以提出(检索静态文本文件,总共223个字节)性能始终正常,245个并发请求：
Connection Times (ms)
min mean[+/-sd] median max
Connect: 15 25 5.8 24 37
Processing: 15 65 22.9 76 96
Waiting: 15 64 23.0 76 96
Total: 30 90 27.4 100 125
Percentage of the requests served within a certain time (ms)
50% 100
66% 108
75% 111
80% 113
90% 118
95% 120
98% 122
99% 123
100% 125 (longest request)
但是,当我同时提出265个同时请求时,其中一部分请求开始花费大量时间来完成：
Connection Times (ms)
min mean[+/-sd] median max
Connect: 13 195 692.6 26 3028
Processing: 15 65 21.3 72 100
Waiting: 15 65 21.3 71 99
Total: 32 260 681.7 101 3058
Percentage of the requests served within a certain time (ms)
50% 101
66% 108
75% 112
80% 116
90% 121
95% 3028
98% 3040
99% 3044
100% 3058 (longest request)
这些结果在多次运行中非常一致.由于还有其他流量进入那个盒子,我不确定硬切断的确切位置,如果有的话,但似乎可疑接近256.
当然,我认为这是由prefork中的线程限制引起的,所以我继续调整配置以使可用线程数增加一倍,并防止线程池不必要地增长和收缩：
<IfModule prefork.c> StartServers 512 MinSpareServers 512 MaxSpareServers 512 ServerLimit 512 MaxClients 512 MaxRequestsPerChild 5000 </IfModule>
mod_status确认我现在运行512个可用线程
8 requests currently being processed,504 idle workers
但是,尝试265个同时请求仍然会产生与之前几乎相同的结果
Connection Times (ms)
min mean[+/-sd] median max
Connect: 25 211 714.7 31 3034
Processing: 17 94 28.6 103 138
Waiting: 17 93 28.5 103 138
Total: 57 306 700.8 138 3071
Percentage of the requests served within a certain time (ms)
50% 138
66% 145
75% 150
80% 161
90% 167
95% 3066
98% 3068
99% 3068
100% 3071 (longest request)
在搜索了文档(和Stack Exchange)之后,我无法进行进一步的配置设置以尝试解决这个瓶颈问题.有什么东西我不见了吗？我应该开始寻找apache之外的答案吗？有没有人见过这种行为？任何帮助将不胜感激.
编辑：
根据Ladadadada的建议,我对阿帕奇进行了调查.我尝试了-tt和-T几次,找不到任何与众不同的东西.然后我尝试对所有当前运行的apache进程运行strace -c,并得到了：
% time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 22.09 0.317836 5 62128 4833 open 19.91 0.286388 4 65374 1896 lstat 13.06 0.187854 0 407433 pread 10.70 0.153862 6 27076 semop 7.88 0.113343 3 38598 poll 6.86 0.098694 1 100954 14380 read
(… abdridged)
如果我正确地阅读(并且忍受我,因为我不经常使用strace),系统调用都不能解释这些请求所花费的时间.在请求甚至到达工作线程之前,它几乎看起来像瓶颈.
编辑2：
有几个人建议,我在网络服务器上再次运行测试(以前测试是从中立的互联网位置运行).结果令人惊讶：
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 11 6.6 12 21
Processing: 5 247 971.0 10 4204
Waiting: 3 245 971.3 7 4204
Total: 16 259 973.3 21 4225
Percentage of the requests served within a certain time (ms)
50% 21
66% 23
75% 24
80% 24
90% 26
95% 4225
98% 4225
99% 4225
100% 4225 (longest request)
底线时间类似于基于互联网的测试,但在本地运行时似乎总是有点差.更有趣的是,个人资料发生了巨大变化.然而,在大量长时间运行的请求时间用于“连接”之前,瓶颈似乎处于处理或等待状态.我不得不怀疑这可能是一个单独的问题,以前被网络限制掩盖了.
再次从与Apache主机相同的本地网络上的另一台机器运行测试,我看到了更合理的结果：
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.8 2 4
Processing: 13 118 99.8 205 222
Waiting: 13 118 99.7 204 222
Total: 15 121 99.7 207 225
Percentage of the requests served within a certain time (ms)
50% 207
66% 219
75% 220
80% 221
90% 222
95% 224
98% 224
99% 225
100% 225 (longest request)
这两个测试共同提出了许多问题,但与此不同的是,现在有一个令人信服的案例可以解决在一定负载下发生的某种严重的网络瓶颈问题.我认为接下来的步骤将分别调查网络层.
解决方法
strace -f -p <PID> -tt -T -s 500 -o trace.txt
在ab测试期间,在您的一个Apache进程上,直到您捕获其中一个缓慢的响应.然后看看trace.txt.
-tt和-T选项为您提供每个系统调用的开始和持续时间的时间戳,以帮助识别慢速系统调用.
您可能会发现一个单一的慢速系统调用,例如open()或stat(),或者您可能会在其后直接调用(可能是多个)poll()调用.如果您发现在文件或网络连接上运行的那个(很可能)会在跟踪中向后查看,直到找到该文件或连接句柄.之前对相同句柄的调用应该让你知道poll()正在等待什么.
看着-c选项的好主意.您是否确保您跟踪的Apache子项在此期间至少提供了一个缓慢的请求？ (我甚至不确定除了同时对所有孩子进行strace之外你会怎么做.)
不幸的是,strace并不能让我们全面了解正在运行的程序正在做什么.它只跟踪系统调用.在一个不需要向内核询问任何内容的程序中可能会发生很多事情.要确定是否发生这种情况,您可以查看每个系统调用开始的时间戳.如果你看到重大差距,那就是时间的流逝.这不容易浮动,无论如何系统调用之间总是存在小的差距.
既然你说cpu使用率很低,那么系统调用之间可能不会发生过多的事情,但值得检查.
仔细观察ab的输出：
响应时间的突然跳跃(看起来在150毫秒到3000毫秒之间没有任何响应时间)表明某个特定的超时发生在某个地方,在大约256个同时连接之上被触发.如果您的RAM或cpu周期正常IO耗尽,则可能会出现更平滑的降级.
其次,慢速ab响应表明3000ms花费在连接阶段.几乎所有人都花了大约30毫秒,但5％花了3000毫秒.这表明网络是问题所在.
你在哪里跑步？你可以在与Apache机器相同的网络上试用它吗？
要获得更多数据,请尝试在连接的两端运行tcpdump(最好在两端运行ntp,这样就可以同步两个捕获.)并查找任何tcp重新传输. Wireshark特别适合分析转储,因为它突出了不同颜色的tcp重传,使它们易于查找.
您可能还需要查看您有权访问的任何网络设备的日志.我最近遇到了一个我们的防火墙问题,它可以处理kb / s的带宽,但它无法处理它接收的每秒数据包数.它最高可达每秒140,000个数据包.你的ab运行的一些快速数学使我相信你会看到每秒大约13,000个数据包(忽略5％的慢速请求).也许这是你达到的瓶颈.这种情况发生在256左右可能纯粹是巧合.
