# 同步性能与服务器友好性

v1.10.0 新增

本页描述的是 **WCPOS v1.10.0** 中引入的同步引擎。若想了解引擎在机制上如何工作，请先阅读 [同步引擎的工作原理](/zh-CN/reference/sync-engine.md)。

大多数 WCPOS 商店运行在共享 PHP 主机上：只有少量 PHP 工作进程，每个 REST 请求都要完整引导一次 WordPress，还有对突发流量限速的安全插件。那些客户端视为免费的请求会拖慢店面、触发限速器，并与收银员自己的流量竞争——而且会被您运行的每一台收银台和每一个浏览器标签页成倍放大。

v1.10.0 的同步引擎把这一点当作设计约束，而不是事后补救：**保护商家的主机是同步引擎职责的一部分。** 本页解释引擎遵循的规则以及支撑它们的测量结果。

## 四条长期规则[​](#the-four-rules "直接链接到 四条长期规则")

引擎中每一项计划性的同步行为都受四条不变式约束：

1. **开销随变化量增长，绝不随目录规模增长。** 任何批量获取之前，总会先有一次廉价的摘要或短路检查。一个没有发生变化的 50,000 件产品的商店，其保持同步的开销与一个没有发生变化的 500 件产品的商店大致相同。
2. **不允许无界扇出。** 每条后台通道都声明单次运行的请求上限，并由自动化测试强制执行。较大的任务以带可恢复游标的有界批次运行——扫描工作会分摊到它的整个排程中，而不是一次性爆发。
3. **维护绝不挡收银员的路。** 让收银台可以开始销售的请求最先运行；完整性审计和后台预热在其后、在空闲时间运行。
4. **压力之下，最先退让的是维护。** 当您的服务器发出困难信号时，引擎会先放慢自己的后台工作，然后才会触及任何面向收银员的部分。

## 同步给您的服务器带来多少开销[​](#request-budgets "直接链接到 同步给您的服务器带来多少开销")

稳态开销由 **同步预设** 决定，它在 **商店健康 → 性能** 中按设备选择：

| 预设         | 检查间隔 | 每次请求的记录数 | 名义每日检查次数 |
| ------------ | -------- | ---------------- | ---------------- |
| 节能         | 5 分钟   | 25               | 288              |
| 均衡（默认） | 60 秒    | 50               | 1,440            |
| 实时         | 10 秒    | 75               | 8,640            |

两个调节项都很重要，而对共享主机来说，真正产生开销的通常是页面重量——一页较重的记录会占用实实在在的服务器时间，而间隔只是把它乘以次数。没有任何预设会使用 100 条记录的最大页；这只能通过自定义滑块达到（间隔 5 秒–5 分钟，10–100 条记录）。

在预设之上还有：

* **一次空闲检查开销很低。** 引擎发送条件请求，因此无变更的检查只会得到一个无正文的 `304 Not Modified` 响应——仍然算一次请求，但没有负载，服务器工作量极小。
* **检查带有 ±20% 的抖动**，因此一组收银机会把请求分散开，而不是同步成突发流量。
* **空闲的收银台会衰减** 到较慢的节奏（10 分钟无交互之后），并在任何活动（包括条形码扫描）时立即恢复。
* **后台维护有上限。** 一次无漂移的完整性检查最多只需几个廉价的聚合页，且 **零** 次明细获取——可被证明与服务器一致的分桶会被直接跳过。当发现漂移时，深入查询每次运行上限为 **两次**，并通过持久化游标续接，而不是一次爆发。完整的删除审计限制为 **每次运行 11 个请求**，摘要预热限制为每次运行 5 个分块。这些上限在代码中声明，并由 CI 强制执行。

应用内的“每日请求数”是名义值

商店健康根据所配置的间隔推导出 *约 N 次请求/天* 的估算值。请把它当作名义检查频率，而不是上限或预测：±20% 的抖动会让实际数量上下浮动，而 `304` 也仍然算一次请求。空闲衰减只会降低快于其 60 秒下限的预设的请求量；它不会让默认的均衡预设变得更慢。

## 服务器吃力时的退避[​](#server-pressure "直接链接到 服务器吃力时的退避")

引擎收到的每个响应都会输入到一个按商店划分的压力监控器。它对以下情况作出反应：

* HTTP `429`（立即反应），
* 反复出现的 `5xx` 错误或传输失败（滚动一分钟内出现三次），
* 持续的缓慢（响应时间中位数超过 2 秒），
* `Retry-After` 响应头，它会成为下一次检查的硬性下限。

其中任何一项被触发时，引擎会 **将变更检查间隔逐级加倍**，同时维护通道会完全跳过本次运行。收银员驱动的请求——搜索、条形码查询、结账——永远不会被限流；目的是卸掉可推迟的负载，而不是拖慢销售。

恢复过程是有意不对称的：退避是即时的，但间隔只有在 **连续十次健康响应** 之后才会回落一级，这样不稳定的服务器就不会在快慢节奏之间来回摆动。压力状态也不会因为商家选择了更快的预设而失效——保护机制运行在所配置层级的下方，并且无法被关闭。

## 保持设备端的响应性[​](#device-responsiveness "直接链接到 保持设备端的响应性")

性能的另一半是收银台本身——后台同步绝不能让界面卡顿。

* **审计让位于事件循环。** 完整性审计会把工作切成块并在块之间让出，使其最长的不间断执行块保持在约 **30 毫秒**——低于人类察觉到延迟的约 100 毫秒阈值。在 10,000 件本地产品上实测，一次完整的审计约耗费 **68 毫秒** 的计算，分散在 17 次以上的让出中；在 50,000 件产品上，低于 300 毫秒。
* **负载之下首个结果依然很快。** 即便有批量应用或完整审计并发运行，首个结果的耗时约定也会在 CI 中被固定——在基准测试环境中，典型目录规模下为个位数毫秒。
* **只有可见的那一页会跨入应用。** 查询工作（筛选、排序、分页）在存储层内部执行，因此一次屏幕更新搬运的是十行数据，而不是一万行。

这些数字来自引擎固定的性能约定测试套件，它在 CI 中隔离运行，预算设定为实测稳态的大约十倍——目的是捕捉数量级的退化，而不是在缓慢的运行器上判定失败。

## 已在真实商店中验证[​](#live-verification "直接链接到 已在真实商店中验证")

这些友好性规则不只经过单元测试。一次针对真实 WordPress 商店的端到端实测检查，验证了在真实主机上最重要的那些不变式：

* 在开店时产品目录渲染出来之前，维护请求（完整性或摘要流量）为 **零**。
* 在开店后的保持期结束之后，最多只有少量廉价的聚合页，且深入明细不超过两次。

这个场景来自一次真实的退化：审计的一个早期开发版本在每次开店时、每台设备上都会发出约 41 个请求（1.2 MB）。取代它的摘要门控设计把一次无漂移的审计缩减到只剩聚合页，别无其他——这一类缺陷现在由 CI 中声明的上限来防守，而不是靠人工评审的警觉。

## 我们不作的声称[​](#honest-limits "直接链接到 我们不作的声称")

有几件事本页有意不去说，因为我们（目前）还没有站得住脚的数据：

* **没有端到端的“初次同步需要 X 分钟”数字。** 初次下载时间绝大程度上取决于您服务器的响应时间和目录规模。设备端应用记录的开销很小（批量应用 10,000 件产品实测低于 10 毫秒的计算时间）；网络传输和服务器才是主导因素。
* **没有“比 v1.9 快 X%”的说法。** 两者的架构差异足够大，单一的比较数字带来的误导会多于信息。结构性差异列在 [v1.10.0 有哪些变化](/zh-CN/reference/sync-engine.md#what-changed-in-v1100) 中。
* 上面的基准数字来自引擎的测试环境（内存存储、隔离运行器）。真实设备和真实商店各不相同；这恰恰就是 **商店健康 → 性能** 显示您收银台过去 24 小时实测请求数和典型响应时间、而不是显示预测值的原因。其数据量数字是一个下限，因为未声明大小的响应计为零。

有关服务器端调优——主机要求、HPOS、缓存以及诊断慢响应——请参见 [服务器性能](/zh-CN/support/performance/server.md)。