做Web开发的人迟早要面对一个问题系统到底能扛住多少并发网上把并发数喊到一万两万的不少可真到上线那一秒接口被打穿、数据库连接池占满、页面直接白屏这种事我见过太多次了。说到底很多项目缺的不是高配置机器而是一次靠谱的高并发场景模拟压测。第一次用siege的时候我觉得这个命令行工具长得太朴素了没有花花绿绿的图表连进度条都省了。但真正跑了几轮之后我发现它把“模拟高并发场景”这件事做得很踏实给定并发数、给定轮次它真能替你把一批用户同时怼到服务端然后把成功率、响应时间、事务速率一五一十摆出来。siege适合谁适合所有需要Web服务性能基线的人后端开发要验证接口抗不抗得住运维要评估线上容量测试要复现线上抖动场景。我自己最常用的三类场景是新接口上线前摸底、老服务重构后对拍性能、以及每次改完数据库连接池或Nginx参数后做前后对比。这篇文章把所有关键参数、真实配置、结果解读和踩坑经验一次说透你照着做就能跑出自己的第一份压测报告。1. 先搞清楚siege是干什么的1.1 它测的是什么不是看热闹是给系统过磅siege是一个HTTP/HTTPS协议层的压力测试工具。它做的事情很简单让指定数量的并发连接同时向目标服务器发起请求持续一段时间或者跑完指定轮次最后统计系统在压力下的表现。它的上报指标很实在成功完成了多少事务、失败了多少、平均响应时间多长、每秒能处理多少事务、传输了多少数据。这些数据就是系统的“过磅结果”。很多人第一次接触siege会下意识把它和“攻击工具”划等号其实不是。它的价值不是证明哪个网站能被打垮而是让你提前知道服务的瓶颈在哪。比如你预期一个商品查询接口在搞活动时要支撑每秒500个请求那就可以先用siege模拟200、400、800并发看响应时间从哪一档开始恶化失败率从哪一档开始抬头。有了这个曲线扩容也好、调参也好、加缓存也好就不再是拍脑袋了。还有一点要讲清楚siege的压力来自网络层它发出的是真实的HTTP请求走的是真实的TCP连接服务端看到的就是一群真实浏览器在访问。相比用脚本在应用内部循环压函数siege更接近用户视角。它能覆盖到域名解析、连接建立、Nginx转发、应用进程处理、数据库查询整个链路所以拿它测出来的响应时间基本就是用户真实验感受到的时间。1.2 为什么选siege而不是自己写脚本或者别的工具有同学问压测我能不能直接写个Python脚本起几百个线程然后sleep一下能但会很累。自己写脚本要处理线程池、超时、结果汇总、并发控制还要保证压测机自己不被瓶颈卡住。这些工作siege早就做完了而且做到了极致简单一条命令参数解决问题。这就是我偏爱它的核心原因——低成本给出可对比的性能基线。另外还会有人问ab也不差wrk也快为什么偏要siege我的回答是看场景。ab的优势是简单但默认只看单URL的GET请求写POST和Header比较别扭。wrk的优势是性能高适合用极小的压测机压出极大的流量但它要写Lua脚本扩展上手门槛更高。siege刚好卡在中间安装方便、参数语义直白、支持多URL列表、支持POST、支持自定义Header还能模拟用户随机浏览路径。对于常规Web系统和高并发场景摸底它是效率最高的那一个。更关键的是siege的输出是普通文本非常便于归档和对比。我今天跑一组明天改完参数再跑一组把两次transaction rate放在一起就能看出变化。这一点在团队协作里很吃香因为谁都可以打开日志看懂结论不需要额外部署一套监控平台。2. 环境准备与最基础的压测命令2.1 三个渠道装好siege安装siege不需要什么复杂的依赖它有三个很主流的安装路径。第一种用系统自带的包管理器这是最省事的办法。在Debian或者Ubuntu系列的机器上执行sudo apt install siege在CentOS、Rocky或者Fedora这类使用yum/dnf的系统上执行sudo yum install siegemacOS上如果装了Homebrew直接brew install siege第二种源码编译安装。有些内网环境或者老系统包管理器里的版本太旧甚至没有收录siege这时候可以到官网下载源码包解压后执行标准的./configure make sudo make install三步走。源码装的版本通常比较新我如果感觉包管理器里版本落后也会这么干。第三种容器环境里直接使用不想污染宿主机的依赖可以拉一个包含siege的基础镜像或者干脆在正在测试的应用容器里临时装一个。压测完成后容器删掉环境干干净净。装完验证一下版本终端输入siege --version能打印出版本号就算成功。不同版本之间参数基本一致但个别新特性有差异我建议压测报告里顺手记录一下siege版本这样后续对比时不会因为工具行为变化产生误判。2.2 一分钟跑出第一份结果装好了先跑一个最小命令感受一下。假设被测服务在本机端口是8080最简单的命令是siege -c 50 -r 10 http://192.0.2.10:8080/这里的-c 50表示同时模拟50个并发用户-r 10表示每个用户循环执行10次请求。单个URL的情况下总请求数差不多就是50×10500个。命令跑完终端里会打印出一整个指标清单这就是你的第一份压测报告。需要提醒的是-c和-r的乘积不是越大越好。第一次跑建议先从-c 20 -r 5开始让服务先热热身也让自己对响应时间有个大概感知。如果一上来就-c 1000服务直接被压死你只能拿到一份失败率爆表的垃圾数据什么都说明不了。另一个常用组合是用时间控制压测时长。比如固定持续2分钟siege -c 100 -t 2m http://192.0.2.10:8080/-c加-t的组合在实际工作中更常用因为真实的线上流量不是按“轮次”来的而是持续不断的。如果你同时指定了-r和-tsiege会优先按时间执行也就是压测在-t指定的时长结束-r不生效。这个细节官方文档写得很清楚容易踩先记住。2.3 别把压测全搞成死冲理解延迟参数很多新人会忽略一个关键点真实用户访问网站不是机枪连发每看一个页面都要停顿几秒。如果你不做任何设置siege在非benchmark模式下默认会有一个延迟用来模拟用户思考时间但如果你加上-b参数就进入了benchmark模式请求之间没有延迟直接满负荷冲击。-b的定位是“极限压测”适合评估系统吞吐上限而真正模拟日常高并发场景应该用-d设置延迟。例如siege -c 200 -d 1 -t 5m http://192.0.2.10:8080/这个命令的意思是200个并发用户每个请求之后随机等待平均1秒左右持续压5分钟。这样产生的效果更接近“200个人同时在用系统”而不是“200台机器在轰炸系统”。我个人的习惯是把两种模式都跑一遍。先用-b摸出系统理论上限再用带-d的模式检查系统在“有人类思考间隙”的真实高并发负载下是否稳定。压测不是把数目喊得越大越专业而是要让数据具备参考意义。所以在你自己的报告里一定要写清楚用的是benchmark模式还是带延迟模式否则后期对比会完全失真。3. 高并发场景怎么配才算真实3.1 用URL列表模拟完整访问路径真实的用户访问不可能只打一个首页。一批用户有的看首页有的翻列表页有的点详情页有的提交订单。如果压测时只盯着一个接口测积累的参数调优参考价值很有限。siege提供了URL列表模式可以一次性把多条URL交给它。先准备一个文本文件我一般命名为urls.txt每行放一个URLhttp://192.0.2.10/ http://192.0.2.10/product/12 http://192.0.2.10/product/34 http://192.0.2.10/list?page1 http://192.0.2.10/cart然后执行siege -c 100 -t 3m -f urls.txt默认情况下每个并发用户会按顺序把列表里的URL从头到尾访问一遍。如果你想让用户的行为更随机加上-i参数它会变成internet模式每次请求从URL列表里随机挑一个。这个特点很适合模拟门户网站、内容站这类访问路径分散的系统。不过要提醒一个容易绕晕的点带多URL列表时-r的“轮次”指的是每个用户把整份列表完整跑一遍。如果列表里有5个URL-c 100 -r 10产生的总事务量通常会比100×10大不少大概相当于100×10×5这个量级。真正关心数字的时候建议先用小并发试跑5秒钟看输出里的Transactions总数反推一下工具对你的URL列表到底是怎么计数的。3.2 只测GET会漏掉真正的瓶颈很多压测场景都绕不开POST请求。登录、提交订单、保存配置这些都是写操作往往比GET更容易暴露出性能问题。如果只压GET你最多验证了读链路而真正在峰值高并发下崩掉的往往是写链路和锁竞争。siege支持在单个URL行里把请求方式声明出来。比如我有一个本地JSON文件order.json内容是提交订单的请求体可以这样压siege -c 50 -t 1m -T application/json -f urls.txt然后在urls.txt里加上这一行http://192.0.2.10/order POST order.json这里POST 告诉siege按POST方式发请求 order.json表示从同目录下的order.json读取请求体。如果是application/x-www-form-urlencoded格式把-T参数改成对应的Content-Type就行。更复杂的场景还需要带登录态。先自己在浏览器里拿一个有效的Cookie字符串然后用-H参数塞进去siege -c 100 -t 2m -H Cookie: sessionabc123 http://192.0.2.10/shop也可以自定义User-Agentsiege -c 100 -t 2m -A Mozilla/5.0 (iPhone) -H Cookie: sessionabc123 -f urls.txt注意如果你用URL列表文件Header是全局生效的。也就是说所有URL请求都会带上同一个Cookie。遇到需要不同用户身份的场景就需要准备多台压测机或者换个思路先用脚本把真实Cookie池生成出来再组织多轮压测。siege本身不擅长做非常复杂的登录态编排这不是它的短板是使用场景要选对。3.3 压测前先确认压测机自己没拖后腿这是最容易忽略、也最影响结论正确性的一步。很多次我调队列参数、调并发线程数结果无论怎么调吞吐都上不去。最后一看问题出在压测机自己身上CPU跑满了或者可用文件描述符不够了压力根本没到服务端。使用siege跑高并发之前至少要确认三件事压测机的CPU和内存是否还有大量余量连接数上限是否够大用ulimit -n看一下当前限制网络带宽是否充裕尤其是测大文件下载的时候。如果发现客户端已经成了瓶颈优先调大系统限制比如临时修改ulimit -n或者调整内核参数里的文件描述符上限。但这只是治标更体面的做法是上多台压测机每一台跑一部分并发最终汇总数据。siege本身是单进程模型它在超高并发时更容易在客户端先耗尽资源所以当你发现单机无论如何也压不上去时不要怀疑服务器先怀疑这台机器。另外如果你用的是笔记本电脑跑压测Wi-Fi和电源管理都可能引入不稳定延迟。我踩过这种坑同样的命令插着电源和用电池跑结果最大响应时间能差出好几倍。所以严肃的压测有条件一定要用有线网络的固定机器。4. 一次压测跑完输出结果怎么读4.1 Transactions、Availability和那堆数字到底什么意思siege跑完会在终端输出一段统计信息看起来像这样Transactions: 10000 Availability: 100.00 % Elapsed time: 59.16 secs Data transferred: 120.46 MB Response time: 0.21 secs Transaction rate: 169.05 trans/sec Throughput: 2.04 MB/sec Concurrency: 36.12 Successful transactions: 10000 Failed transactions: 0 Longest transaction: 4.02 Shortest transaction: 0.01对于第一次接触的人这些指标每个都得看懂否则你只会记得一个“百分之百成功”其他全是乱码。我整理过一个速查表列在下面。指标名含义怎么用Transactions完成的总事务数一次请求一个事务用来估计总请求量Availability成功率等于成功事务占总事务比例低于99.9%就要警惕Elapsed time整个压测持续的时间用于计算每秒速率Data transferred压测过程中总传输的数据量估算带宽成本Response time每个事务平均响应时间核心性能指标越低越好Transaction rate每秒完成的事务数可以约等于QPS吞吐量越高越好Throughput每秒传输的数据量单位KB/s或MB/s看带宽是否被打满Concurrency压测期间实际观测到的平均并发数用于验证是否打到目标并发Successful transactions成功事务数量统计总数时用Failed transactions失败事务数量排查问题最关注Longest transaction单次请求最长耗时看尾部延迟偶然卡顿会体现在这里Shortest transaction单次请求最短耗时看理想情况下最快响应这里面有个逻辑关系值得多说一句Concurrency并不等于你命令里的-c数。-c 100只是让siege起100个工作进程去发请求但每个请求之间可能有延迟服务端处理也有快慢所以压测期间系统实际观测到的并发数通常低于设定值。上面例子里设置了比较高的目标但实际Concurrency只有36.12这说明大量“用户”其实在等待延迟而不是同时挂在服务端上。你想让系统承受更高的实际并发就要减少请求间隔或者用-b去掉人为延迟。4.2 Failed transactions上升先别急着加机器压测结果里最刺眼的就是Failed transactions。很多人一看失败率高了就赶紧调连接池、加服务器但我的建议是先搞清楚失败发生在哪一层。失败可以从几方面分连接层失败客户端连不上服务端常见原因是并发连接数超过上限、队列溢出、TCP握手超时。读写超时请求发出去了但服务端没能在默认超时时间内返回siege会记一次失败。应用层错误HTTP返回码不是预期值。默认情况下非200的响应会被siege判为失败比如返回了502、503、504或者接口本身返回500。判断方法也很简单压测的同时开另一个终端看服务端的访问日志和应用日志。如果访问日志里几乎所有请求都到达了但应用日志里有大量超时或数据库错误那问题大概率在应用内部。如果访问日志本身有大量缺失那问题出在更前面的Nginx、网络或者连接队列。还有一种很误导人的情况接口虽然返回HTTP 200但业务逻辑内部其实报错了比如下单接口吞掉了异常继续返回成功。这种压测看起来Availability是100%实际业务成功率早就崩了。所以压测绝不能只看HTTP状态码业务侧最好做一次小规模的正确性校验。这也是我坚持压测时业务日志必须全开的理由。4.3 拿Transaction rate和Response time画曲线别孤立的看单次结果单次压测结果只能说明当前那一分钟系统表现不足以指导扩容。正确姿势是阶梯加压分别用50、100、200、400并发各跑一轮把每轮的Transaction rate、Response time和失败率记录下来连成一条趋势曲线。这就是我压测报告里最核心的一张表随着并发上升事务速率是持续上涨还是到达某个点后开始回落响应时间是从哪一档开始急剧恶化比如我常常见到的情况是并发100时事务速率是320并发200时变成340并发400时反而跌回280。这个拐点往往说明服务资源已经被打满继续加并发只会雪上加霜。为了在日志里一眼区分不同并发轮次siege提供了--mark参数。比如siege -c 200 -t 2m --markconc200 -f urls.txt--mark会把标记字符串写进结果行后续整理日志时你能直接看出这组数据是200并发跑出来的不会互相混淆。两次压测之间最好等20到30秒让服务把连接池、日志队列、CPU负载都吐干净否则上一轮的余波会污染这一轮的数据。5. 常见问题与排查技巧实录5.1 一上来就搞千级并发服务直接雪崩我见过不止一个团队上线前拍脑袋定了“压测目标一万并发”然后一条命令-c 5000 -b下去应用进程存活的没剩几个。这种压测方式既伤机器也得不到数据属于典型的自嗨式压测。正确节奏应该是先探底再加压。比如先跑-c 20 -b看正常响应时间是多少然后逐渐翻倍往上加每一轮都停留在能拿到完整指标的档位。遇到失败率突然升高的档位回落一档再跑一次确认拐点是否可复现。这个过程就像试水而不是直接跳进深水区。我还会给siege设置一个合理的超时时间防止请求卡死导致压测机资源被占满。命令里可以这样加siege -c 200 -t 3m --timeout10 -f urls.txt超过10秒没有响应就会主动断开这样既不会让压测进程永远等下去也能让Failed transactions反映出真实超时情况。没有超时配置时服务端一旦出现半开连接siege可能会长时间挂着拖慢整轮压测。5.2 结果太漂亮先检查是不是客户端瓶颈有一种情况你设了1000并发跑完发现Availability 100%Transaction rate高得惊人。先别高兴去压测机上看一眼top如果CPU已经满到99%网络流量顶到网卡上限那这个1000并发根本没真正打到服务端大把请求还没出门就被客户端自己消化掉了。这类问题的排查路径很固定。压测过程中打开两个终端一个跑siege另一个跑top或vmstat观察客户端负载。如果压测机本身已经过载就需要降低目标并发或者用多台压测机分摊。另外检查服务端的接入层日志看看那个时间段的请求量是否和siege统计的Transaction rate匹配如果服务端看到的请求量明显偏少说明部分压力在客户端就损失了。还有一个常见隐藏因素URL里的域名解析。如果压测目标是一个域名而不是IP每个请求都要经过DNS解析压测机自己的DNS缓存可能成为瓶颈。严肃的高并发场景我通常会直接压IP再用-H Host: www.xxx.com把Host头带上这样既绕开DNS解析又能测到正确的虚拟主机。5.3 日志和报告怎么留才能让对比有意义siege跑完不要只截图一个终端窗口。花30秒做个简单归档后面能省很多事。我常用的命令会加上--log参数siege -c 200 -t 3m --log/var/log/siege/conc200.log -f urls.txt日志文件里会按时间记录每一轮的请求结果。加上前面说的--mark参数后期想找出某轮数据grep一下标记字符串就行。一份能说服人的压测记录至少要有这几项siege版本、被测服务版本、压测机配置、并发数、URL列表内容、关键参数是否用-b、延迟多少、超时多少、原始输出和日期。少了任何一项过两周回头看这份数据很可能没法复现也就失去了对比意义。还有个容易被忽略的细节压测时顺手把服务端的系统负载也记录一下比如CPU、内存、磁盘IO、MySQL连接数。因为性能瓶颈不一定在HTTP层可能在容器CPU配额上可能在数据库连接池上。只有把客户端压测指标和服务端资源指标放在同一个时间轴上才能讲清楚“数字变差”到底是因为哪一层资源耗尽。6. 数字拿到手之后从指标走向调优6.1 先看响应时间分布再看平均响应时间平均响应时间很容易骗人。系统里1%的请求慢到5秒直接把平均值从0.2秒拉高到0.5秒但你如果只盯着平均值会被误导以为整体都变慢了。siege默认只输出平均值、最长和最短没有中位数和分位数所以我每次跑完压测都会把应用网关或者Nginx的access log导出来按响应时间算一下P50、P90、P99。这里分享一个我常用的判断逻辑P50保持稳定P99开始明显变差说明大部分请求处理得挺好但有一小部分请求撞上了资源排队比如数据库连接池等待、线程池等待。先查慢查询和锁等待往往比盲目加大机器更有效。如果P50和P99一起恶化整个系统才真的是被打满了这时候扩容或限流才有意义。siege在压测过程中真正擅长的是给出“系统开始变差的那条边界线”。边界线找到了再去分析响应时间分布定位那部分“狂暴”的尾延迟来源。两者配合才会形成完整调优闭环。6.2 结合日志和连接状态定位瓶颈在哪一层一次高并发压测发现问题之后别急着改配置。我会按下面顺序排查先看Nginx或接入层日志有没有大量连接超时或502。如果接入层过载优先查worker_processes、keepalive、upstream连接池。再看应用进程CPU是打满还是大量线程在等待。CPU高多半是代码效率问题或者GC压力大线程大量等待多半是依赖的下游服务慢比如数据库或Redis。再查数据库连接数是否打到max_connections慢查询数量是否突增。这里经常是最终瓶颈所在。举个例子我遇到过压测时Transaction rate一直卡在300上不去Failed transactions开始上涨。打开数据库监控一看连接数顶满慢查询日志里塞满了某条SQL的变体。优化这条SQL的索引之后同一套siege命令Transaction rate直接跳到了1200。这个案例告诉我压测工具本身不解决问题但它能精准地把问题指给你看。6.3 一份完整的压测执行清单可以照着做因为团队里总有新人接手压测任务我整理过一份压测执行清单现在也分享出来确认压测目标URL或URL列表把接口路径、请求方式、请求体准备好。在测试环境或隔离环境执行绝不直接在生产环境做破坏性压测确有必要必须限时、限量、有回滚方案。先用curl手动请求一次确认返回内容符合预期。看压测机资源是否充足必要时调高文件描述符上限。从低并发开始跑第一轮比如-c 20 -t 30s观察基本指标。逐级增加并发每轮记录Transaction rate、Response time、Availability、Failed transactions。压测过程中同时监控服务端CPU、内存、连接数、慢查询等指标。导出siege日志加上--mark标记并归档压测结果。对比多轮数据找到拐点再决定调优方向。这套流程看起来朴素但没有一步是多余的。我见过太多压测报告只有一句“并发500时系统正常”连URL列表都没附上这样的报告既无法复现也不能指导决策。把清单执行完压测结论才算真的立得住。最后分享一个我自己的习惯每次压测前我会先用curl -w把单个请求的响应时间和错误码打出来作为这轮压测的基准。压测中再开一个终端持续观察服务端日志看到Failed transactions跳动的瞬间马上切过去看当时的堆栈或慢查询。工具负责施压人负责在压力下找到真相。siege用好了就是一个能帮你提前发现线上灾难的哨兵。