先确定容量验收标准

美国服务器运行WooCommerce商城，不能只按“预计有多少个访客”来选容量。需要同时核算峰值请求、结算并发、应用进程、数据库读写和数据增长，再用接近真实业务的测试确认瓶颈。容量应以最先触及限制的环节为准：应用进程不够时，加大数据库配置未必有用；数据库查询变慢时，单纯增加应用服务器也未必能改善结算体验。

开始规划前，先写下三项验收条件：

• 业务目标：明确可接受的商品页、购物车和结算响应时间，以及订单提交成功率。应以业务要求或现有基线为准，不套用通用性能数字。
• 峰值场景：说明预计的同时在线人数、页面请求量、促销峰值持续时间和下单速率。在线人数不等于同时执行数据库操作的人数。
• 增长边界：估算订单、商品、用户及日志的增长速度，并确定在何种容量告警或业务增长情况下重新评估。

若目前没有真实流量数据，先记录现有访问日志、应用响应时间和数据库指标；新站则以预计活动流量建立测试场景，并把测试结果标注为估算，不要当作上线后的实际容量保证。

一、准备可用于核算的数据

在调整服务器前，先确认运行环境和数据口径，避免拿不完整的信息做容量结论。

1. 记录软件与部署方式：记录操作系统、PHP版本、数据库类型与版本、WooCommerce版本，以及应用与数据库是否共用主机。参数名称和可用功能会随版本及部署方式变化，修改前应核对当前环境。
2. 区分页面类型：至少拆分商品浏览、搜索或筛选、购物车、结算、账户操作和后台任务。静态资源或已缓存页面的负载，不能代替购物车与结算的动态负载。
3. 收集峰值而非日均值：按分钟或更短的业务监控周期观察请求量、响应时间、错误率、CPU、内存、磁盘等待、数据库连接数和慢查询。日均数据会掩盖短时活动峰值。
4. 确认订单存储方式：WooCommerce可因配置和版本不同使用不同订单存储方式。统计订单表时，先确认当前实际使用的存储模式，不要默认所有站点的表结构相同。
5. 准备测试环境和恢复点：负载测试优先在与线上配置接近的测试环境进行。若必须在生产环境验证，应安排低风险时段、限制测试量，并提前确认数据库备份可恢复、配置可回退。

这些数据用于回答两个不同问题：服务器当前能承受多少请求，以及业务增长后数据库和存储会增加多少。两者应分别核算，再交叉验证。

二、把并发订单换算成资源需求

先区分并发用户、请求和订单

“同时在线一千人”不代表一千个人同时下单。部分用户可能停留在页面，部分请求被缓存，还有一部分请求会执行购物车更新、库存检查、优惠计算或订单写入。容量规划应关注动态请求及其执行时间。

可先用下面的关系估算活跃请求：

活跃请求数 ≈ 每秒请求数 × 请求平均处理时间

这是用于初步判断的近似关系，不是服务器性能承诺。例如响应时间变长，即使请求速率不变，正在占用应用进程或数据库连接的请求也会增加。因此测试时要同时观察请求速率和响应时间，不能只看访问人数。

订单峰值应另行核算：

• 记录活动期间每分钟或每秒的订单提交量，并区分成功提交、重复提交和失败请求。
• 测试购物车与结算流程中的库存校验、优惠规则、税费计算、运费计算和支付回调等真实逻辑。
• 观察订单写入之外的关联操作，例如库存更新、邮件发送、后台任务和插件触发的查询。
• 若订单集中在短时间提交，按峰值区间规划，而不是用全天订单平均值除以时间。

可用“峰值每秒动态请求数 × 单次请求实际查询数”作为数据库请求量的初步估算入口，但查询数必须从实际应用或数据库监控中取得。不同插件、缓存命中率和页面类型会改变这一数值，不能凭经验给所有商城套一个固定倍数。

识别最先达到上限的环节

不要把某一个指标孤立地当作结论。CPU升高可能来自数据库，也可能来自PHP代码；连接数增多可能是正常峰值，也可能是慢查询导致连接长期不释放。判断时应对照同一时间段的请求量、响应时间、进程和数据库状态。

三、按应用和数据库分别估算容量

应用进程数要受内存约束

若使用PHP-FPM，可用“留给PHP工作进程的内存 ÷ 峰值单进程实际内存”估算进程上限。留给PHP的内存应先扣除操作系统、数据库、Web服务、缓存和必要的系统余量；单进程内存应通过高峰期观测，而不是直接照抄默认值。

例如，若应用与数据库共用主机，PHP进程数不能按整机内存计算。每增加一个工作进程，都可能增加内存占用、数据库连接和并行查询压力。进程数设置过低会排队，设置过高则可能耗尽内存或压垮数据库。

核对步骤：

1. 在正常业务或测试负载下记录PHP进程的实际内存占用。
2. 计算扣除其他服务和系统余量后的可用内存。
3. 估算进程上限后分阶段调整，不一次大幅增加。
4. 观察响应时间、内存、交换空间、数据库连接和错误日志。
5. 若进程增多后响应未改善、数据库等待上升或内存告警加剧，应回退并排查下游瓶颈。

PHP-FPM具体参数及服务名称依安装方式而异。修改前先查看当前配置和服务定义；保存原配置副本，确认语法检查方式，再按当前版本的管理方式平滑重载。

数据库容量不能只看订单表大小

数据库占用不仅包括订单数据，还包括商品、用户、索引、日志、临时空间及插件创建的数据。WooCommerce更新存储方式或安装插件后，表结构也可能变化。应统计整个数据库和各表的实际占用，并记录增长趋势。

在MySQL兼容数据库中，可使用只读查询查看各表的估算数据与索引空间：

SELECT
  table_schema,
  table_name,
  table_rows,
  data_length,
  index_length
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY data_length + index_length DESC;

说明：部分存储引擎的行数是估算值；此查询显示的是表级统计，不等于精确备份文件大小。应结合数据库自身监控、备份文件大小和磁盘实际占用判断。若当前会话没有选中目标数据库，先在受控数据库客户端中确认连接对象，再执行查询。

容量预测可按业务数据分项进行：

预测数据量 ≈ 当前实际占用 + 预计新增订单数据 + 预计新增商品与用户数据 + 索引及运行空间余量

新增订单数据的估算应以一段真实业务周期内的数据库增长为依据，并注明订单量、插件和日志策略等条件。不要只用“单笔订单平均大小”推算全部数据库，因为索引、订单项目、元数据和插件表可能带来额外占用。

数据库内存配置也不应只追求把数据尽可能放入内存。应观察实际工作集、缓存命中、查询延迟、连接数和系统剩余内存。数据库与应用共用主机时，数据库增加内存可能挤占PHP进程空间；分开部署时，则要关注应用到数据库的连接规模和数据库端的并发处理能力。

四、执行容量测试并完成验收

测试场景要覆盖真实交易路径

测试前在测试环境准备接近线上规模的商品、库存、用户和订单数据，并确保使用测试支付流程，不向真实用户发送通知或产生真实扣款。测试数据应与线上隔离，测试结束后按环境管理流程清理；不要在生产数据库上执行无边界的造数或压测。

测试顺序建议从低风险到高负载：

1. 单用户冒烟测试：完成浏览商品、加入购物车、修改数量、进入结算和提交测试订单，确认基础功能正常。
2. 逐步增加浏览负载：观察商品页和搜索请求的响应、缓存效果、CPU及应用进程。
3. 加入购物车与结算负载：逐步增加动态请求，关注应用队列、数据库连接、慢查询和订单写入。
4. 验证目标峰值及持续时间：按业务计划的峰值速率运行，并覆盖可能出现的持续活动时段。测试工具应控制请求速率，避免一次性突发把测试环境打成非真实场景。
5. 验证恢复能力：停止施压后检查排队是否消退、错误是否停止、数据库连接是否恢复，确认系统回到测试前基线附近。

验收不以“页面能打开”为止

每轮测试都应记录时间、测试版本、并发设置、请求速率、成功与失败数量，以及关键资源指标。成功条件至少包括：

• 核心页面和结算流程满足事先确定的响应时间目标。
• 订单成功率达到业务要求，且订单数量、库存变化和支付测试结果能够相互核对。
• 峰值时没有持续增长的请求队列、数据库连接等待或错误率。
• 内存、磁盘空间及数据库连接没有逼近已设定的告警边界。
• 停止测试后系统能恢复，错误日志没有持续出现新的资源耗尽或数据库异常。

如果响应时间变差但CPU仍有余量，优先检查慢查询、外部调用、插件逻辑和锁等待；若PHP进程持续占满且数据库正常，再核对应用进程配置和代码处理时间；若数据库等待与连接拥塞同步增加，先分析查询及事务，不要立刻通过增加连接数掩盖问题。每次只调整一类变量，重新测试后再判断效果。

五、失败处理、回滚与复核留证

出现异常时，按影响范围由小到大处理：

• 测试请求失败或订单未生成：核对测试支付配置、应用日志及订单状态，不要直接重复提交可能产生重复订单的请求。
• PHP进程排队或内存告警：停止测试，恢复到最近一次已验证的进程配置，检查单进程内存和慢请求。
• 数据库连接耗尽或锁等待：停止增加负载，保存数据库状态与慢查询记录，先定位长事务、慢查询或连接未释放问题。
• 磁盘空间告警：停止可能持续写入的测试，确认数据库、日志和临时文件分别占用；不要在未确认用途及备份前删除数据文件。
• 修改后功能异常：恢复原配置并按当前服务管理方式重新加载，随后执行冒烟测试。数据库结构变更或数据清理不能用简单恢复配置代替，应先确认备份和恢复流程。

配置变更前保存原文件、变更内容和生效时间；数据库操作前确认备份完成且具备恢复条件。若要调整数据库参数，先记录原值、修改范围、重启或重载影响，再按数据库版本的官方支持方式操作。容量测试结束后保留测试结果、监控截图或导出数据、错误日志、配置差异和回滚记录，避免只留一个“通过”结论。

复核周期应与业务变化相匹配：促销活动前、订单量明显增长后、重要插件或存储方式变更后，都重新检查峰值请求、订单写入、数据库增长和磁盘余量。容量结论应注明适用的流量、数据规模、软件版本和测试条件；超出这些条件时，重新测量比沿用旧估算更可靠。