压测是检验Web服务器真实承载能力的必经之路。相比Apache自带的ab，用Go语言编写的boom工具安装简单、跨平台、输出直观，非常适合快速验证Nginx的并发处理能力。本文从环境搭建讲起，一步步演示如何用boom对Nginx发起并发测试，并解读测试结果中的各项指标。
一、准备环境：安装boom工具与Nginx
boom是一个受ab启发的命令行压测工具，底层基于Go的net/http库实现。它最大的优势是单文件分发，不依赖额外的运行时环境，下载即用。以Linux为例，如果你的机器上有Go环境，可以直接执行以下命令安装：
go get -u github.com/rakyll/boom
安装完成后，执行boom -h能看到帮助信息就说明安装成功。如果不想装Go，也可以从项目的发布页下载对应平台的二进制文件，解压后放到系统PATH目录即可。
Nginx这边建议用默认配置先跑通流程，后续再针对压测结果做调优。启动后可以先用curl确认服务正常：
nginx # 启动服务 curl -I http://127.0.0.1/
返回200状态码说明Nginx已经在正常监听。测试时有一个细节要注意：压测机和被测服务器尽量分开部署，如果boom和Nginx跑在同一台机器上，压测本身会占用CPU，导致测出的数据失真。
二、boom的基本用法与常用参数
boom的核心用法非常简洁，最简单的形式是指定请求数和并发数：
boom -n 1000 -c 100 http://127.0.0.1/
其中-n表示总请求数，-c表示并发数。上面这条命令的含义是用100个并发连接总共发送1000个请求。执行后boom会输出一份统计报告，包括平均延迟、请求延迟分布、每秒请求数等关键数据。
除了基本参数，还有几个选项在实战中很常用：
-m：指定HTTP方法，比如POST接口压测时使用-h：添加自定义请求头，例如-h "Authorization: Bearer xxx"-d：设置请求体，配合-c的content-type头可以压测POST接口--timeout：设置单请求超时时间，避免慢请求拖长整体测试-allow-insecure：跳过HTTPS证书校验，压测自签名证书站点时需要
压测POST接口的一个典型示例如下：
boom -n 5000 -c 200 -m POST \
-h "Content-Type: application/json" \
-d '{"name":"test"}' \
http://127.0.0.1/api/user注意JSON数据中的双引号需要用shell语法正确包裹，否则boom会解析失败。建议先用小并发数验证请求格式无误，再逐步加大压力。
三、解读测试结果与Nginx调优方向
boom的输出报告大致包含这些指标：Latency（延迟分布，分为10%、25%、50%、75%、90%、99%分位）、AvgLatency（平均延迟）、Fastest（最快请求）、Slowest（最慢请求）以及RPS（每秒请求数）。看报告时不要只盯着平均值，90%和99%分位延迟更能反映用户真实体验。如果平均值很低但99%分位延迟很高，说明存在明显的长尾问题。
当压测数据不理想时，可以从Nginx配置入手排查。首先是worker进程数，建议设置为CPU核心数，可以通过nproc命令查看：
nproc # 输出4，则在nginx.conf中设置 # worker_processes 4;
其次是连接数相关配置。worker_connections控制单个worker能处理的最大连接数，默认值通常只有1024，高并发场景下可以适当调大。同时别忘了worker_rlimit_nofile要配合修改，否则会受系统文件描述符上限限制。系统层面的ulimit -n也需要同步放开，一般压测环境建议至少设置为65535。
另一个容易被忽略的点是keepalive。boom默认使用HTTP keep-alive复用连接，如果Nginx端开启了keepalive_timeout且值合理，RPS会有明显提升。如果发现压测过程中出现大量502或504，还要检查后端应用的处理能力以及Nginx的proxy_read_timeout等超时参数。压测的本质是暴露瓶颈，逐项排查才能让Nginx发挥出应有的性能。
四、boom与ab、wrk的对比
ab是最老牌的压测工具，几乎所有发行版都自带，但它单线程的设计导致高并发下自身容易成为瓶颈，测出的RPS往往偏低。boom采用Go的协程模型，能轻松跑出数千并发，且输出的分位数延迟比ab更实用。wrk则更进一步，支持Lua脚本做复杂场景，性能也是三者中最强的，但学习成本相对高一些。
简单场景下boom的易用性最好：单二进制、参数直观、报告清晰。如果只是想快速验证一次Nginx配置改动的效果，boom完全够用；如果需要复杂的多接口混合压测和脚本化控制，再考虑wrk或专业压测平台。工具没有绝对的优劣，关键是根据测试目标选择合适的方案，并保证压测环境尽量贴近真实生产场景，这样得出的数据才有参考价值。