源码安装apache后需手动验证编译产物功能完整性，并分层开展基准性能与并发极限测试：先确认服务稳定运行，再用ab等工具逐级施压，最后结合系统指标定位瓶颈。
源码安装 Apache 后，不能直接依赖预编译包自带的工具链做完整压测，需手动验证编译产物功能完整性，并分层开展基准性能与并发极限测试。核心思路是：先确认服务可稳定运行，再用标准化工具逐级施压，最后结合系统指标定位瓶颈。
一、确认 Apache 编译产物可用且配置合规
编译安装完成后，必须验证二进制文件、模块加载和基础服务响应是否正常：
- 执行 httpd -V 查看编译参数（如
--prefix、--enable-so、--enable-rewrite），确认关键模块已启用； - 运行 httpd -t 检查配置语法无误，避免因配置错误导致后续压测结果失真；
- 启动服务后，用 curl -I http://127.0.0.1 验证 HTTP 响应头返回正常（状态码 200、Server 字段含正确版本）；
- 检查 httpd -M 输出中是否包含
mpm_event_module（推荐高并发场景）或mpm_prefork_module（兼容旧模块），确保 MPM 模型匹配预期用途。
二、使用 ab（Apache Bench）快速跑通基础基准
ab 是最轻量、最贴近 Apache 自身行为的命令行压测工具，适合验证单机吞吐与延迟基线：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 若未安装，从源码目录的
support/下复制 ab 到/usr/local/bin/，或重新编译时确保--enable-modules=most包含mod_so； - 基础命令示例：ab -n 5000 -c 100 http://127.0.0.1/，测试 5000 次请求、100 并发；
- 务必加 -k 参数启用 Keep-Alive，否则 TCP 连接反复建立会严重拉低 RPS；
- 关注输出中的 Requests per second（RPS）、Time per request (mean) 和 Percentage of the requests served within a certain time（如 99%
三、逼近并发极限：多轮递增 + 系统监控联动
单纯提高 -c 值易导致连接超时或服务崩溃，需配合资源观测逐步逼近真实极限：
- 按阶梯递增并发数：例如从
-c 50 → 100 → 200 → 500，每轮运行 60 秒（用-t 60），记录 RPS 变化趋势； - 同时在另一终端运行 top -b -n 1 | grep httpd 或 pidstat -u -p $(pgrep httpd) 1，观察 CPU 使用率是否持续 >90%；
- 用 ss -s 查看 ESTAB 连接数，比对
MaxRequestWorkers设置值（位于mpm_*.conf），确认是否已达连接上限； - 当 RPS 不再上升、错误率（Failed requests）明显增加、或平均延迟陡增（如翻倍），即为当前配置下的并发拐点。
四、补充验证：引入 sysbench 与磁盘 I/O 关联分析
Apache 性能瓶颈常不在 HTTP 层，而在底层资源——特别是静态文件服务依赖磁盘读取时：
- 用 sysbench fileio --file-total-size=2G --file-test-mode=rndrw --time=30 run 测量随机读写 IOPS，若低于 200 IOPS（机械盘）或 10K+（NVMe），则静态资源响应可能受限；
- 对比开启
EnableSendfile On与关闭时的 ab 结果，验证零拷贝是否生效（仅对大文件明显）； - 若使用 mod_php 或反向代理后端，需单独对 PHP-FPM 或上游服务做同等压测，避免误判 Apache 本身能力。
