核心是分步定位瓶颈:先用ab快速摸底,观察错误率与响应时间突变点;同步检查apache进程数、连接状态、状态页及错误日志;排除mpm配置、系统文件描述符和内存等硬限制;最后用jmeter开展带业务逻辑的进阶压测验证稳定极限。
装完 apache http server 后,测试最大并发连接数性能极限,核心是“模拟真实压力 + 观察瓶颈点 + 验证配置生效”。不靠猜测,靠数据驱动。重点不是一次跑出最大值,而是分步定位哪一层先卡住。
用 ab 工具快速发起并发压测
Apache Bench(ab)是最轻量、最直接的验证工具,无需额外部署,适合初筛:
- 基础命令:
ab -n 1000 -c 200 http://localhost/—— 发起 1000 次请求,200 并发 - 加 KeepAlive 更贴近真实场景:
ab -n 1000 -c 200 -k http://localhost/ - 逐步加压:从 -c 50 开始,每次 +50,观察错误率、响应时间突变点(如出现大量
Connection refused或apr_socket_connect(): Connection refused) - 注意:ab 本身是单机工具,客户端资源(如本地端口耗尽、CPU 占满)也可能成为瓶颈,建议在另一台同网段服务器上运行 ab
确认 Apache 实际承载能力是否达标
压测时同步查服务端状态,判断是 Apache 真的撑不住,还是被系统限制或配置锁死:
Apache Superset 是一个广泛采用的开源 BI 平台,用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时,此技能非常有用。
- 查当前活跃进程/线程数:
pgrep httpd | wc -l(prefork)或ps -eL | grep httpd | wc -l(event) - 看连接状态分布:
netstat -ant | awk '{print $6}' | sort | uniq -c | sort -n,重点关注ESTABLISHED是否接近MaxRequestWorkers,以及大量TIME_WAIT或SYN_RECV表示连接堆积 - 检查 Apache 状态页(需启用
mod_status):curl http://localhost/server-status?auto,看BusyServers/IdleServers和Total Accesses变化趋势 - 查看错误日志:
tail -f /var/log/httpd/error_log,搜索server reached MaxRequestWorkers或out of memory
排除系统级和配置级硬限制
很多“撑不住”其实不是 Apache 能力问题,而是被拦在门外:
- 确认 MPM 模式及配置已生效:检查
httpd -V | grep -i mpm,再核对httpd-mpm.conf中对应模块(如<ifmodule mpm_prefork_module></ifmodule>)下的MaxRequestWorkers(Apache 2.4+,旧版叫MaxClients)是否设够,且ServerLimit≥MaxRequestWorkers(超 256 必须显式设置) - 检查系统限制:
ulimit -n(文件描述符)、cat /proc/sys/net/core/somaxconn(全连接队列)、sysctl net.ipv4.ip_local_port_range(本地端口范围),必要时调高 - 内存是否真够?用
ps -o pid,rss,comm -C httpd | awk '{sum+=$2} END {printf "%.1f MB\n", sum/NR/1024}'算单进程平均内存,再估算理论上限:可用内存 ÷ 单进程内存 ≈ 最大进程数
进阶验证:用 JMeter 做更真实、可监控的极限测试
ab 适合快速摸底,JMeter 更适合业务级压测(如带登录态、多接口组合、结果断言):
- 新建线程组,设置“线程数(用户数)”为待测并发值,“Ramp-Up 时间”设为 60 秒以上,避免瞬间冲击
- 添加 HTTP 请求,默认复用连接(Keep-Alive 自动开启),加响应断言确保返回成功
- 配合后端监控:同时看 Apache 的
server-status、系统top/vmstat、网络ss -s,记录 CPU、内存、TCP retransmit、TIME_WAIT 数量等关键指标 - 逐步提高线程数,直到错误率 > 1% 或平均响应时间翻倍,此时的并发数即为当前配置下的稳定极限










