你的网站能扛多少人同时访问？压测一次就知道

一个所有站长都该能回答、但多数答不上来的问题：你的网站能同时扛住多少人访问？服务器买了、带宽选了，但系统真实的承载力始终是个未知数——直到某天一篇文章爆了、一场活动开了，流量洪峰把答案用事故的方式告诉你。压力测试就是把这一刻提前搬到实验室：用工具模拟并发，半小时的模拟换洪峰来临时的从容，让容量从猜测变成数字——数字化的容量，才能支撑数字化的扩容决策。

先分清两类测试性能测试分两种：负载测试，测系统在响应正常的前提下，最大能支持多少并发用户——关注的是极限值在哪；压力测试，持续加压超过极限，看系统在超负荷下的表现——什么时候开始出错、出错率多少、恢复能力如何。一次完整的容量评估两者都要：负载测试告诉你「能扛多少」，压力测试告诉你「扛不住时会怎么死」——后者同样重要，优雅降级和当场崩溃是两种完全不同的系统素养——前者保住体验，后者保住数据。

工具选择：从ab到JMeter入门首选ab（Apache Bench）：Apache自带的小工具，一行命令发起并发请求，秒级出结果——请求数、并发数、每秒吞吐、响应时间分布，全都有。适合单接口、单页面的快速验证。进阶用JMeter：开源的完整压测平台，下载解压即用，支持多线程并发、接口测试、场景编排、结果可视化——从单接口到混合业务场景都能覆盖。再往上有Wrk、Locust等各有侧重的工具，但绝大多数站长的需求，ab加JMeter的组合已经绰绰有余。工具不在多，在用得熟：一个ab跑日常，一个JMeter跑场景。

压测的四个步骤第一步，定目标：预估真实业务的峰值并发——日均流量的十倍，或历史峰值的五倍，取高者作为测试基准。第二步，搭环境：尽量在独立环境测，避免直接压生产；必须压生产时选业务低峰期，并发从小到大爬坡。第三步，执行并记录：每个并发级别下的吞吐、错误率、响应时间都记录成表——数据的变化趋势比单点数值更有信息量。第四步，找瓶颈：响应时间陡增的拐点、错误率开始出现的并发数，就是系统的容量边界；配合服务器监控（CPU、内存、连接数），能进一步定位瓶颈在应用、数据库还是带宽——压测给现象，监控给病因。

读懂结果：三个关键指标吞吐量（每秒处理请求数）看系统的处理能力；响应时间看用户体验——注意看分位数，百分之九十五的响应时间比平均值更诚实，平均值好看而长尾糟糕的系统，用户抱怨往往就来自长尾；错误率看稳定性边界——错误率从零到非零的那个并发数，就是必须告警的红线。吞吐量、响应时间分位数、错误率，三个指标合起来，就是系统的完整画像。

压测之后的动作测出的容量低于预期，按瓶颈对症优化：应用慢就加缓存、数据库慢就查索引、带宽满就升级；高于预期也别浪费——数据拿去校准监控告警的阈值，把压测红线设进告警系统，真实流量逼近时提前扩容。压测不是一次性的仪式：每次改版、每个大促前重测一遍——容量随代码和流量的变化而漂移，去年的数据今年不作数。容量这件事，猜测的代价永远高于测量——一次压测半天，一次事故一周。