展会宣传或广告集中投放后，平时正常的网站突然变慢，客户提交咨询也开始失败。一天有多少访问，与某一分钟能否处理集中请求，是不同问题。评估承载能力，需要理解客户何时到达、会做什么，以及哪些业务结果必须保持可靠。
先把“流量大”转换成可讨论的场景
访问量、同时在线人数和请求到达速度不能相互替代。同样一千名客户，分散在一天浏览资料，与集中在一分钟提交申请，对网站产生的压力不同。统计口径应先确定时间范围和实际操作。
活动页面也不一定是全部负载来源。客户可能同时搜索产品、读取图片、上传附件或提交表单。评估时应按真实使用比例描述这些动作，避免只重复打开一个简单页面来代表全部业务。
响应时间要观察分布与失败
平均响应快，仍可能有一部分客户等待很久。Microsoft 的性能监测指南建议使用响应时间分位数观察分布。例如，P95 表示约百分之九十五的样本不超过对应时间，能帮助识别多数客户之外的较慢请求。
同时需要看失败比例、完成量和业务正确性。表单返回成功却没有保存需求，或同一预约产生冲突，都不能算业务通过。性能评估应与功能结果一起确认。
不同页面可能在不同环节受限
静态介绍页面与需要即时查询的功能，处理成本不同。大量图片可能影响传输；复杂查询、外部服务等待或提交操作，则可能影响后续响应。单纯增加一种资源，不一定解决真正受限的环节。
缓存可以帮助重复读取稳定内容，但不能替代实时业务规则，也不能让客户看到别人的私人资料。具体优化应根据观察到的限制决定，避免为了“高并发”引入当前业务用不到的复杂结构。
测试应有可控范围与停止条件
模拟负载前，需要明确测试环境、目标范围、数据处理和停止条件，并避免误触发真实短信、付款或客户通知。测试只覆盖经过授权的资源，不能把第三方服务当作无限可用的测试对象。
受控测试可以逐步增加负载，观察稳定时段、集中到达和恢复过程。若出现异常，应记录发生在哪类操作以及业务影响，再决定调整方向。一次短测试没有报错，不能代表所有峰值场景都可用。
把活动预估换成可验证的负载说明
以下数字仅用于说明计算方式：预计 10 分钟内有 600 人进入活动页，其中 20% 提交咨询。平均每秒约 1 人到达，咨询平均每秒约 0.2 次。这既不是总 HTTP 请求数，也不是峰值；一名访客还会读取图片、查询产品，真实到达可能集中在某一分钟。
因此测试说明应另外列出页面资源、主要业务动作、到达集中程度和停留方式。若只反复请求一张静态首页，报告中的吞吐量不能作为咨询保存能力的证据。未知峰值应列为假设，再分别检查平缓到达与短时集中，而不是从平均值直接推算可承受人数。
| 检查阶段 | 观察什么 | 判断依据 |
|---|---|---|
| 逐步增加负载 | 完成量、响应分布、错误及资源等待 | 找出从何种业务组合开始恶化 |
| 持续保持 | 队列是否越积越多，结果是否完整 | 短时能响应不等于持续可处理 |
| 停止新增后 | 积压消退、资源释放、业务对账 | 恢复后没有遗留重复或未解释的丢失 |
通过条件应在测试前约定，例如某种设备与网络下的关键动作耗时范围、允许的错误类别以及数据完整性。测试记录必须注明环境、版本、资料规模和外部依赖是否模拟；这些条件不同，数字就不能直接横向比较。测试结束核对正式测试记录与预期数量，性能合格也不能掩盖业务错误。
需要建设或优化相关网站功能？
计划开展集中推广、展会或在线报名活动，可以私聊页面客服，说明预计访问时间、主要客户动作和重要功能。具体评估、测试与优化范围，将结合实际网站沟通。
参考资料：Microsoft：性能指标、响应分布与监测。
