企业官网建设流程全解析

接手压测任务的人，十有八九是从一条Siege命令开始的。我见过太多类似场景：同事跑完一条siege -c 200 -t 60s http://target，把报告甩过来说“系统扛不住了”，结果我一看，Availability掉到95%，但压测机自己的文件描述符早就撞了1024的墙，端口也快耗尽，一堆请求压根没到服务器。这是Siege最典型的“假失败”——工具没调明白，锅全让业务背了。

这篇文章不打算给你贴一遍siege --help输出，那是手册干的事。我想聊的是真正在极限压测里能用得上的参数调优思路：并发模型怎么理解、时间和延迟怎么控制、请求怎么构建才像真实用户、报告里的数字该怎么解读，以及命令行之外那些决定压测成败的系统级配置。配合一个从默认参数跑到稳定压测的完整过程，把每一步的选择理由和数据变化都摊开讲。适合刚接触Siege的后端开发、运维和专职压测同学，也适合那些已经跑过一阵子但总觉得结果“不太可信”的人。

1. 先搞懂Siege的压测模型，再谈参数调优

1.1 Siege的工作方式：进程、连接与计时循环

Siege和其他压测工具最大的不同，在于它的并发模型是“进程池”而不是“线程池”。启动时它会根据-c指定的并发数fork出对应数量的子进程，每一个子进程就是一个独立的虚拟用户。这个用户进程做的事情很简单：向目标URL发起HTTP请求、等待响应、记录耗时，然后进入下一轮循环，直到压测时间耗尽或请求次数达标。

这个模型有个直接后果：并发数越高，压测机上的进程数就越多。默认情况下每个进程只维持一个TCP连接，也就是说-c 1000意味着压测机上会同时存在1000个进程、1000个活跃连接。这和Jmeter那种一个JVM里用线程池模拟并发的思路不同，Siege的方式更耗系统资源，但对请求隔离性更好，一个进程出了异常不会污染其他用户的行为。

理解了进程模型，再去看参数就清楚多了。-t控制压测总时长，-r控制每个进程的请求次数，-c控制进程数量，-d控制每个进程两次请求之间的间隔。这四个参数基本决定了压测的“形状”——是短时间高并发轰击，还是长时间中低并发浸泡。

1.2 为什么默认参数距离“极限”很远

默认配置下的Siege跑出来的结果，几乎不可能代表系统的真实上限。最大的坑就是请求延迟。Siege的默认配置里有一个1秒的“思考时间”，也就是每个虚拟用户发完一个请求后要等1秒再发下一个。这个设计模拟的是真实用户浏览网页的节奏，但对于压测来说，它会把每秒请求数压得非常低——100个并发用户跑1秒，理论最大QPS也只有100。

另一个坑是超时和重试机制。默认情况下，如果请求在指定时间内没收到响应，Siege会记录一个失败并继续下一个循环。但在极限压测场景下，服务器响应变慢是常态，如果客户端超时设置不合理，大批请求会因此被判定为失败，混淆真正的问题。

再加上压测机本身的限制（后面第5章详细展开），默认参数下跑出的报告里，混杂了服务器瓶颈、客户端瓶颈和工具自身限制三部分噪声。要做极限压测，第一步就是把这些噪声从结果里剥离出去。

2. 并发与时间：极限压测的核心控制参数

2.1 -c并发数与-b基准模式：从100到5000的路径

并发数是压测里最直观的参数，也是最容易被用错的参数。-c指定的是同时活动的虚拟用户数，不是每秒请求数。它和QPS之间的关系取决于每个请求的响应时间：如果平均响应时间是100毫秒，那么一个用户1秒最多发10个请求，100个并发用户的理论QPS上限就是1000。

极限压测的操作路径应该是梯度加压，而不是“一步到位”。我习惯从100并发起跑，按50或100的步长递增，每个档位跑60秒以上，记录响应时间、成功率、QPS三个核心数据的拐点。比如从100加到200时QPS翻倍，从500加到600时QPS几乎不涨但响应时间开始飙升，那500附近就是这台服务器在当前配置下的并发上限。

-b参数在极限压测中几乎必开。它的含义是去掉请求之间的延迟，让每个进程以最大速率连续发请求。没有-b的情况下，Siege默认延迟1秒，就算把并发加到5000，实际QPS也可能只有可怜的几千，根本不是“极限”。开了-b之后，请求会像洪水一样涌向服务器，这时候测出的才是系统处理能力的上限。

2.2 -t与-r：压测时长的正确打开方式

-t和-r分别控制压测持续时间和每个用户的请求次数。极限压测推荐用时间而不是次数。原因很实际：次数模式下，如果压测中途大量请求失败，Siege的进程会快速重试把次数耗完，导致实际压测时间远比预期短，数据根本不具有统计意义。时间模式则固定了压力窗口，无论中间发生什么，60秒就是60秒，结果可比性更强。

时长怎么选？低于30秒的数据抖动太大，慢启动、连接池预热、JIT编译这些因素还没稳定下来，压测就结束了。我一般以60秒为基准档位，排查问题时用30秒快速验证，观测长期稳定性时会跑到5到10分钟。超过10分钟对大多数场景意义不大，除非你做的是内存泄漏验证或长时间浸泡测试。

有个细节需要留意：-t和-r在Siege里是互斥的，同时指定时后出现的参数会覆盖先出现的。建议一条命令里只保留一个，避免踩到“为什么我设了30秒结果跑了几分钟”这种坑。

2.3 -d延迟参数：给客户端留条活路

-d设置每个请求之间的延迟，单位是秒，支持小数。开了-b后，-d会被忽略，两者不需要同时出现。但在某些场景下，我会有意不用-b而是把-d设成很小的值，比如0.01秒。

为什么这么做？因为-b模式下Siege会尽最大可能轰击服务器，如果压测机的性能弱于服务器，那么压测机自己会先成为瓶颈——CPU跑满、进程调度不过来、端口耗尽，测出来的数据反映的是压测机的上限，而不是服务器的承载能力。用一个很小的延迟代替完全无延迟，可以在“极限压测”和“客户端不拖后腿”之间找到平衡点。

这也延伸出一个判断技巧：如果压测过程中压测机自己的load average已经超过CPU核心数的两倍以上，说明流量瓶颈可能在客户端。这时候要么降低并发，要么提高延迟，让服务器的真实处理能力浮出水面。

3. 让压测请求贴近真实业务

3.1 Cookie、请求头与身份认证场景

很多业务接口不是裸奔的，登录态、鉴权头、自定义Header是常态。直接压不带认证的接口，得到的数字好看，但对生产环境没有任何参考意义。Siege支持通过-H自定义请求头，还可以设置-A来指定User-Agent。

带上Cookie压测的典型路径是：先用浏览器或curl登录目标系统，从浏览器开发者工具里复制Cookie值，然后拼进命令。比如siege -c 100 -b -t 60s -H "Cookie: sessionid=xxxx; token=yyyy" "http://target/api/data"。Cookie字符串里有空格或特殊字符时，记得整个Header用双引号包起来。

更复杂的场景，比如Token会动态刷新，或者Cookie只在压测开始前几分钟内有效，单纯依赖-H就不够了。这种场景下我建议先用脚本（curl或Python）把登录后的Cookie写入文件，再通过Siege的-f文件列表配合-H使用。虽然后续Cookie过期仍然是个问题，但大多数压测场景在几分钟内不会遇到，用来做极限压测足够了。

3.2 POST请求与Content-Type细节

POST请求在Siege里用-P指定数据体，用-T指定Content-Type。最容易踩坑的是JSON接口。很多人写成-P '{"name":"test"}'就完事了，结果服务端返回415，因为Siege默认的Content-Type是application/x-www-form-urlencoded。正确做法是同时指定-T "application/json"，两个参数配合使用，缺一不可。

还有一个shell转义陷阱。JSON数据里有双引号，放在Shell命令行里要么用外层单引号包裹，要么对内层引号做转义。我的习惯是外层用单引号，并且绝不和内部转义混用，否则很容易出现数据被Shell半路拆散，发出去的请求体和预期完全不一致。压测前先用siege -g抓取一下响应头，确认请求能被正常处理，再进入正式压测，能省不少排查时间。

如果POST数据比较长，推荐把数据写到文件里，用-P /path/to/data.json指定。注意这个文件路径不会做二次解析，文件内容会原样作为请求体发送，所以文件里不要有多余的换行或空格。配合-T指定正确的Content-Type，效果和-H "Content-Type: application/json"一致，选哪个看个人习惯。

3.3 多URL压测：用-f代替单URL

极限压测单URL的问题是：它测的是系统“最坏情况”下的单一接口吞吐上限，但生产环境的流量是分散的。真实用户进来会先访问首页、再点接口、偶尔拉一次静态资源，每种请求的开销和响应时间完全不同。单URL压测得到的结果，很难直接推导到混合流量场景。

用-f urls.txt可以加载一个URL列表。文件里每一行放一个完整的URL，Siege会按顺序循环访问。加上-i参数后，Siege会在URL列表中随机跳跃，模拟真实用户无规律的访问路径。这个组合是我做混合场景压测时的默认配置。

关于URL文件有几个小坑：行尾不要留空格，URL必须写完整协议头http://或https://，空行会导致Siege报错。文件里如果包含POST接口，可以在URL后用逗号分隔POST数据，比如http://target/api/login,username=tom&password=123，这在Siege 4.0以上版本是支持的。不过这个特性不同版本行为略有差异，我倾向于把POST场景单独压，GET混合场景走-f文件，避免参数不兼容的麻烦。

4. 输出结果解析：从报告数字中定位真实瓶颈

4.1 核心指标解读：别只盯着Availability

Siege跑完会在终端输出一大段报告。很多人只看Availability（成功率），这是最粗糙的用法。真实瓶颈藏在一组数字的组合关系里。

Transactions是完成的事务数，Elapsed time是实际压测时长，两者的比值就是Transaction rate，即每秒事务数。这个数字才是“这台系统能扛多少QPS”的答案。Response time平均值和Longest transaction则揭示了延迟特征：如果平均值还在100毫秒以内，但Longest transaction跑到了5秒以上，说明系统存在明显的长尾延迟——可能有超时重试、GC停顿或者某条慢查询在拖后腿。

Concurrency这个字段也值得留意。它表示压测过程中实际观测到的平均并发连接数，理想情况下应该接近-c设定的值。如果实测并发远低于设定值，说明系统的响应太快，每个用户还没等下一轮循环就完成了请求；如果实测并发高于设定值，说明请求在排队，系统的处理速度已经跟不上了。

数据对比的逻辑是：并发从100升到200，QPS翻倍，响应时间涨幅有限，说明系统有余量；再往上加到300，QPS开始走平甚至下降，响应时间翻倍，说明已经过了拐点。拐点附近的吞吐量就是这台服务器的极限承载，这个数字要比“Availability低了几个点”有说服力得多。

4.2 -g日志与Fine-tuning经验

-g参数在Siege里是“抓取模式”，它只发送请求并打印HTTP响应头，不进入压测循环。这个参数常被用来快速验证请求格式是否正确——Header有没有带对、Cookie是否有效、接口是否返回预期状态码。我每次压测前都会先用-g打一发，确认请求本身没问题，再进入正式压测，省去了大量因为请求构造错误导致的无效压测时间。

-l参数用于记录压测结果到日志文件，默认写入当前目录下的siege.log。极限压测时我强烈建议开启日志，并且每次压测都带上命令行和并发参数，以便事后复盘。压测过程中参数经常会来回调整，如果没有日志，最后根本记不清哪份数据是哪次跑出来的。

从我自己的习惯来看，一次严肃的极限压测至少要留下三样东西：原始报告输出、完整命令（含所有参数）、压测机和服务器的资源监控数据。前两样Siege能直接给，第三样需要自己额外采集。缺少资源占用数据的压测报告，充其量只能回答“系统在某种压力下表现为多少QPS”，回答不了“瓶颈在CPU、内存、磁盘还是网络上”。

5. 系统级调优：命令行之外的硬门槛

5.1 本地文件描述符与端口耗尽

压测并发数一旦过千，最先崩溃的往往不是服务器，而是压测机自己。Linux默认的ulimit -n（文件描述符上限）通常是1024，一个进程里开的文件、连接、Socket都要占用文件描述符。当Siege fork出1000个进程，每个进程一个连接时，本机文件描述符立刻耗尽，新连接根本无法建立。

压测前第一件事就是调整压测机的文件描述符上限。临时生效可以用ulimit -n 65535，永久修改要写在/etc/security/limits.conf里。注意ulimit命令对当前Shell生效，新开的终端要重新设置。

端口耗尽问题更隐蔽。客户端的TCP连接需要占用本地端口，Linux默认的本地端口范围通常是32768-60999，总共不到3万个端口。在短连接场景下，一个请求结束后连接进入TIME_WAIT状态，端口短时间内不能被复用。当QPS很高时，几秒钟就能把可用端口消耗干净，报错表现为Cannot assign requested address。

5.2 内核网络参数调整

针对压测机和服务器的网络参数，有几个内核配置在极限压测时几乎逃不掉。

net.ipv4.ip_local_port_range可以扩大本地端口范围，比如改成1024 65535，能提供更多可用端口。短连接的TIME_WAIT问题，可以通过开启net.ipv4.tcp_tw_reuse（Socket重用处于TIME_WAIT状态的连接）和调短net.ipv4.tcp_fin_timeout（默认60秒，可以降到15或30秒）来缓解。这些参数在压测场景下的收益非常明显——不开的话，高并发短连接压测几乎不可能稳定跑满30秒。

需要提醒的是，tcp_tw_reuse在一些NAT网络环境下可能出现连接异常，生产环境要谨慎开启。但对于压测这种可控场景，尤其是压测机和服务器走内网直连时，开启带来的吞吐收益远大于风险。修改这些参数用sysctl -w即时生效，重启后失效；要持久化可以写入/etc/sysctl.conf。

还有一个容易被忽略的参数是net.core.somaxconn，它控制Socket监听队列的长度。如果压测突发连接数超过队列深度，新连接会被直接拒绝，表现为客户端收到connection refused。默认值是128，对高并发场景明显不够，建议和内核参数一起调大。

5.3 服务器端的连接队列与并发上限

压测不只是客户端的事，服务器端配置直接影响结果。Nginx的worker_connections、Tomcat的acceptCount、Spring Boot的server.tomcat.max-threads，这些参数定义了服务器能同时处理的连接和线程数量。如果服务器端没有为高并发做准备，就算压测机把流量打满，结果也会被服务器的连接队列扛不住而中断。

服务器端的access_log在高并发下是隐藏杀手。全量记录每次请求的日志，会让磁盘IO成为瓶颈，压测出的QPS远低于真实处理能力。极限压测前，我通常会把服务端的access_log临时关掉或改为采样记录，压测完再恢复。这不是作弊，而是为了剥离日志IO对性能的干扰，聚焦应用本身的处理能力。

如果压测目标是HTTP服务，确认一下Nginx是否开了gzip。压缩会显著消耗CPU，如果生产开了gzip而压测环境没开，压测结果会比生产乐观不少；反过来也一样。压测环境的配置应尽量和生产对齐，否则得到的数字说服力有限。

6. 一次完整的极限压测调优实录

6.1 默认参数首跑：遇到“假的失败”

以一个维护中的订单查询API为例，目标是在响应时间可接受（P99小于500毫秒）的前提下，找出系统的最大QPS。压测机4核8G，服务器8核16G，Nginx + Spring Boot应用，内网直连。

第一轮用了最常规的命令：siege -c 200 -t 60s http://server:8080/order/query?userId=1001。结果Availability只有94%，Transaction rate 320，Response time平均1.8秒，Longest transaction直接8秒。单看这些数字，结论很悲观——系统连200并发都撑不住。

但压测过程中我注意到一个反常现象：压测机自己的load average已经飙到12左右，而服务器的CPU才用了40%。这说明压力根本没有完整作用到服务器上，压测机成了瓶颈。检查后发现两件事：一是默认的ulimit还是1024，Siege fork出200个进程后文件描述符已经告急；二是压测机没有开-b，默认延迟又进一步拖慢了实际流量。

6.2 参数调整后的压力曲线

第二轮先解决客户端问题。执行ulimit -n 65535，扩大本地端口范围，开启连接重用，然后用siege -c 200 -b -t 60s重新压。这一轮Availability回到了100%，Transaction rate变成880，平均响应时间降到200毫秒。数据变化非常大——同样的200并发，上一轮320QPS是假象，这一轮880QPS是去掉客户端瓶颈后的真实值。

接下来做梯度加压。以200为起点，每次加100，每个档位跑60秒，记录QPS和响应时间。200并发时QPS 880，300并发时QPS 1150，400并发时QPS 1200，500并发时QPS却回落到980，同时平均响应时间从300毫秒飙升到1.5秒。拐点很明显：这台服务器在400到500并发之间触顶，继续加压只会增加排队时间，不会带来更多吞吐。

再把响应时间拆开看，300并发时P99约350毫秒，满足500毫秒以内的目标；400并发时P99已经到480毫秒，接近红线。把两个维度综合起来，最终结论是：该系统在“P99小于500毫秒”约束下的推荐并发上限约350，对应QPS约1150。

6.3 系统配合后的稳定结果

第三轮考虑服务器端优化。关闭access_log，调大Nginx的worker_connections，把系统的somaxconn从128提到1024。再次用350并发压60秒，结果QPS从1150小幅提升到1250，响应时间P99保持在420毫秒附近。

这一轮的结果并不是服务器的真实极限——直接把并发提高到500以上，QPS仍然能涨，但响应时间会持续恶化。极限压测的目标不是“最大化QPS”，而是在满足业务SLA的前提下找到最大吞吐。明确了这一点，最终压力定位在350并发和1150QPS附近，对应的资源水位、错误率、响应时间分布都有了完整的基线。后续做容量规划、上云评估或者版本迭代对比，都拿这一组数据做基准。

7. 常见问题与排查速查表

7.1 经典报错与处理

压测过程中踩过的坑，整理成一张速查表，按现象排查会快很多：

7.2 避坑心得：如何让压测结果有说服力

压测报告的可信度，取决于你能不能回答三个问题：请求是否真实、客户端是否拖后腿、数据是否可复现。

请求是否真实，说的是请求头、Cookie、请求体要和生产流量一致。很多压测结果偏乐观，是因为压测请求太“干净”——没有Cookie、没有带业务参数、没有真实负载。反过来，有些压测结果偏悲观，是因为压到了不存在的内耗逻辑上。建议每次压测前用-g抓一下响应头，确认请求确实命中了预期的业务逻辑。

客户端是否拖后腿，看压测机的CPU和load average。数据采集中，压测机的CPU占用超过70%、load超过核数的1.5倍时，建议优先优化压测机配置，而不是盲目质疑服务器。正常压测中服务器CPU打到了90%以上而压测机CPU很闲，这份结果才有说服力。

数据可复现，是每次压测都保留完整命令参数、Siege版本、系统内核参数和配置变更记录。压测不是跑一次就完事，后续做优化对比、容量评估都需要回头对照。数据没有上下文，就是一堆无意义的数字。

我个人实际操作中还有一个习惯：压测结束后等30秒到1分钟，再检查一次服务是否恢复正常，响应时间是否回到基线。有些系统在压测期间表现尚可，但压测结束后线程池、连接池迟迟不释放，恢复过程要花好几分钟。这种“压完不回弹”的现象，也是生产事故的隐患。能扛住压测本身不算完，扛完之后还能干净利落地恢复，才是系统真正健康的标志。