# 服务器性能

服务器性能直接影响您的 WCPOS 应用程序的速度和响应能力。POS 会发起大量 REST API 调用，因此 **服务器响应时间是首要瓶颈**——POS 速度在很大程度上取决于托管质量。本指南帮助您使用内置的指标和故障排除技术监视、诊断和优化服务器性能。

## 最低服务器要求[​](#minimum-server-requirements "直接链接到 最低服务器要求")

为了在生产环境中获得响应迅速的 POS，我们建议至少满足以下条件：

CPU

<!-- -->

: 4 个以上 CPU 核心

RAM

<!-- -->

: 4 GB 或更多

PHP

<!-- -->

: PHP 7.4+（推荐 8.x）

Database

<!-- -->

: MySQL 8.0+ 或 MariaDB 11.x

Storage

<!-- -->

: SSD 或 NVMe

SSL

<!-- -->

: 必须使用 HTTPS——没有它 WooCommerce REST API 将无法工作

共享主机通常不够

共享主机的 PHP 工作进程往往太少、内存太低，无法应对会发起大量并发 API 调用的 POS 工作负载。对于生产环境的 POS 使用，强烈推荐使用 **VPS 或托管的 WordPress 主机**。`WordPress.com` 托管也已知存在 REST API 兼容性问题（一些用户从大型商品目录中只能看到 9–10 个产品）——推荐使用自托管的 `WordPress.org` 以获得完全兼容性。

### 社区验证的优化方案[​](#community-validated-optimisation-stack "直接链接到 社区验证的优化方案")

用户报告使用以下组合可获得最佳 POS 性能：

* **MariaDB 11.4**（在 WooCommerce 工作负载下比 MySQL 更快）
* **启用 HPOS**（见下文）
* **LiteSpeed 或 Redis** 对象缓存
* **NVMe** 存储
* **启用 PHP OPcache**

## 503 错误[​](#503-errors "直接链接到 503 错误")

503 错误始终来自服务器端

`503 Service Unavailable` **不是 POS 的 bug**——它表示服务器无法处理该请求。请检查：

1. 服务器负载和可用资源
2. PHP 工作进程（可能已耗尽）
3. PHP 内存限制——增加到 **256 MB 或更多**
4. 您的虚拟主机服务器日志（联系您的主机；他们可以看到应用程序看不到的内容）

## WooCommerce 版本兼容性[​](#woocommerce-version-compatibility "直接链接到 WooCommerce 版本兼容性")

WooCommerce 更新偶尔会破坏 POS。请始终先在[暂存站点](/zh-CN/support/troubleshooting/plugin-conflicts.md#before-you-start-use-a-staging-site)上更新 WooCommerce，并保持 WCPOS 为最新版本，以便它包含最新的兼容性修复。

已知问题：

* **WooCommerce 10.5.0**——破坏了 POS 中的产品加载（症状：仅显示约 10 个产品；条形码扫描和搜索停止工作），并引入了一个实验性产品缓存，可能导致 **postmeta 膨胀** 和内存耗尽。**修复方法：** 将 WCPOS 更新到最新版本（它包含该修复和一个清理迁移），或将 WooCommerce 回滚到 [10.4.3](https://downloads.wordpress.org/plugin/woocommerce.10.4.3.zip)。

如果某次 WooCommerce 更新破坏了 POS，请将 WooCommerce 回滚到上一版本（通过该插件 WordPress.org 页面的 **Advanced** 标签页）并报告问题。

## 了解服务器指标[​](#understanding-server-metrics "直接链接到 了解服务器指标")

WCPOS 在每次数据获取操作（产品、订单、客户等）时自动收集服务器性能指标。您可以在[日志](/zh-CN/support/logs.md)屏幕中查看这些指标。

### 典型的服务器指标[​](#typical-server-metrics "直接链接到 典型的服务器指标")

```
{

  "total": "24692",

  "execution_time": "76.64 ms",

  "server_load": "[15.20605469,16.16357422,16.76806641]"

}
```

**细分：**

* **`total`** - 处理的记录数量（24,692 产品 ID）
* **`execution_time`** - 完成操作所需的时间（76.64 毫秒）
* **`server_load`** - 1、5 和 15 分钟的服务器负载平均值

## 服务器负载解释[​](#server-load-explained "直接链接到 服务器负载解释")

服务器负载表示在不同时间段内的平均系统负载：

* **第一个值** - 1 分钟平均值（15.21）
* **第二个值** - 5 分钟平均值（16.16）
* **第三个值** - 15 分钟平均值（16.77）

### 负载解读[​](#load-interpretation "直接链接到 负载解读")

服务器负载值可能会产生误导，应该谨慎解读：

负载值可能会误导

服务器负载平均值并不总是与性能直接相关。负载值高（15+）的服务器如果资源充足且优化良好，仍然可以非常响应。**专注于执行时间，而不仅仅是负载值。**

**一般指导原则：**

* **负载与 CPU 核心的关系** - 在 8 核心服务器上，8.0 的负载意味着充分利用
* **持续与暂时** - 短暂的峰值是正常的，持续的高负载可能表明问题
* **性能更重要** - 响应迅速的高负载服务器优于低负载的慢服务器

**注意事项：**

* **执行时间随着时间的推移而增加**
* **负载持续增长**而没有解释
* **高负载与慢执行时间同时出现**

## 性能基准[​](#performance-benchmarks "直接链接到 性能基准")

### 执行时间指导[​](#execution-time-guidelines "直接链接到 执行时间指导")

| 操作         | 良好    | 可接受    | 较差     | 关键 |
| ------------ | ------- | --------- | -------- | ---- |
| **产品获取** | < 100ms | 100-500ms | 500ms-2s | > 2s |
| **订单创建** | < 200ms | 200-800ms | 800ms-3s | > 3s |

### 记录计数考虑[​](#record-count-considerations "直接链接到 记录计数考虑")

执行时间应与记录计数合理缩放：

```
// Good scaling examples

{"total": "100", "execution_time": "15.2 ms"}    // 0.15ms per record

{"total": "1000", "execution_time": "89.4 ms"}   // 0.09ms per record

{"total": "10000", "execution_time": "234.1 ms"} // 0.02ms per record



// Poor scaling examples

{"total": "100", "execution_time": "500.0 ms"}   // 5.0ms per record

{"total": "1000", "execution_time": "8000.0 ms"} // 8.0ms per record
```

## 诊断性能问题[​](#diagnosing-performance-issues "直接链接到 诊断性能问题")

### 第 1 步：监控日志[​](#step-1-monitor-the-logs "直接链接到 第 1 步：监控日志")

1. 从导航抽屉中打开 **日志**
2. 执行慢操作（同步产品、创建订单等）
3. 查找相应的日志条目
4. 展开上下文以查看指标

### 第 2 步：分析指标[​](#step-2-analyse-the-metrics "直接链接到 第 2 步：分析指标")

**高执行时间 + 高服务器负载 = 服务器资源问题**

```
{

  "total": "5000",

  "execution_time": "3500.0 ms",

  "server_load": "[12.45, 11.23, 10.87]"

}
```

*解决方案：增加服务器资源或优化服务器配置*

**高执行时间 + 正常服务器负载 = 插件/数据库问题**

```
{

  "total": "1000",

  "execution_time": "2800.0 ms",

  "server_load": "[1.23, 1.45, 1.67]"

}
```

*解决方案：识别慢插件或优化数据库查询*

**正常执行时间 + 高服务器负载 = 一般服务器超负荷**

```
{

  "total": "2000",

  "execution_time": "150.0 ms",

  "server_load": "[8.90, 9.12, 8.45]"

}
```

*解决方案：减少其他进程的服务器负载或升级资源*

## 常见性能问题[​](#common-performance-problems "直接链接到 常见性能问题")

### 1. 服务器资源不足[​](#1-insufficient-server-resources "直接链接到 1. 服务器资源不足")

**症状：**

* 一直高的服务器负载 (> 4.0 在大多数服务器上)
* 所有操作的长执行时间
* 经常超时

**解决方案：**

* **升级 CPU** - 更多核心更好地处理并发请求
* **增加 RAM** - 减少磁盘 I/O 并改善缓存
* **使用 SSD 存储** - 显著改善数据库性能
* **优化 PHP 设置** - 增加 memory\_limit、max\_execution\_time

### 2. 较慢的数据库查询[​](#2-slow-database-queries "直接链接到 2. 较慢的数据库查询")

**症状：**

* 高执行时间与正常服务器负载
* 特别慢的产品/订单获取
* 日志中的数据库相关错误代码

**解决方案：**

* **启用 WooCommerce HPOS** - 最大的数据库性能提升
* **使用对象缓存** - 如果您的主机支持，使用 Redis 或 Memcached
* **保持 WordPress 更新** - 核心更新通常包括数据库优化
* **限制帖子修订** - 在 wp-config.php 中添加 `define('WP_POST_REVISIONS', 3);`

### 3. 插件干扰[​](#3-plugin-interference "直接链接到 3. 插件干扰")

**症状：**

* 插件更新后突然的性能下降
* 某些操作明显比其他操作慢
* 高执行时间与正常服务器负载

**故障排除：**

1. **在暂存环境中测试** - 禁用除了 WooCommerce 和 WCPOS 以外的所有插件
2. **测量基线** - 记录最少插件的执行时间
3. **逐步启用** - 一次添加一个插件以确定问题所在
4. **检查插件钩子** - 查找钩入 WooCommerce 动作的插件

**常见问题插件：**

* 在产品操作期间使用重型 SEO 插件
* 复杂的库存管理系统
* 实时分析/跟踪插件
* 编码不良的自定义插件

### 4. WordPress/WooCommerce 配置[​](#4-wordpresswoocommerce-configuration "直接链接到 4. WordPress/WooCommerce 配置")

**症状：**

* 性能不一致
* 日志中的内存相关错误
* 后台管理慢

**优化检查表：**

* **PHP 版本** - 使用 PHP 8.0 及以上以获得更好的性能
* **WooCommerce HPOS** - 启用高性能订单存储（见下文）
* **WordPress 缓存** - 如果可用，启用对象缓存
* **WooCommerce 设置** - 优化产品图像大小

### WooCommerce 高性能订单存储 (HPOS)[​](#woocommerce-high-performance-order-storage-hpos "直接链接到 WooCommerce 高性能订单存储 (HPOS)")

最大的性能提升

**HPOS 是您可以为 WooCommerce 做出的最重要的性能改进之一。** 它将订单存储在自定义数据库表中，而不是 WordPress 帖子表中，显著提高了订单数量较多的商店的性能。

**好处：**

* **更快的订单查询** - 订单存储在优化的数据库结构中
* **减少数据库负载** - 将订单从帖子/页面中分隔
* **更好的可扩展性** - 高效处理大量订单
* **改善后台性能** - 更快的订单管理屏幕

**如何启用：**

1. 转到 `WooCommerce > Settings > Advanced > Features`
2. 启用“High-performance order storage”
3. 按照迁移过程进行操作

**了解更多：**

* [WooCommerce HPOS 文档](https://woocommerce.com/document/high-performance-order-storage/)
* [HPOS 迁移指南](https://woocommerce.com/document/high-performance-order-storage/#section-3)

## 服务器监控最佳实践[​](#server-monitoring-best-practices "直接链接到 服务器监控最佳实践")

### 1. 定期性能检查[​](#1-regular-performance-checks "直接链接到 1. 定期性能检查")

* **每周审查** - 检查日志中的性能趋势
* **基线测量** - 记录正常的执行时间
* **高峰时段监控** - 在高流量期间进行监控

### 2. 设置性能警报[​](#2-set-performance-alerts "直接链接到 2. 设置性能警报")

监控以下警告信号：

* 一直执行时间 > 1000ms
* 服务器负载 > 5.0 持续一段时间
* 日志中频繁出现超时错误

### 3. 容量规划[​](#3-capacity-planning "直接链接到 3. 容量规划")

跟踪增长趋势：

* **记录计数增长** - 产品、订单、客户
* **性能下降** - 执行时间如何缩放
* **资源利用** - CPU、内存、磁盘使用

## 服务器优化策略[​](#server-optimisation-strategies "直接链接到 服务器优化策略")

### 1. WordPress/WooCommerce 最佳实践[​](#1-wordpresswoocommerce-best-practices "直接链接到 1. WordPress/WooCommerce 最佳实践")

**启用 HPOS:**

* 对 WooCommerce 影响最大的性能改进
* 有关详细信息，请参见上面的 HPOS 部分

**PHP 配置（咨询您的主机）：**

```
memory_limit = 512M

max_execution_time = 300

max_input_vars = 3000
```

**WordPress 配置：**

```
// In wp-config.php - limit post revisions

define('WP_POST_REVISIONS', 3);



// Enable WordPress debug logging if needed

define('WP_DEBUG_LOG', true);
```

### 2. 主机级优化[​](#2-hosting-level-optimizations "直接链接到 2. 主机级优化")

**对象缓存：**

* 询问您的主机关于 Redis 或 Memcached 的可用性
* 许多托管的 WordPress 主机自动提供此功能

**PHP 版本：**

* 使用 PHP 8.0 以上以获得显著的性能提升
* 大多数主机允许轻松切换 PHP 版本

**服务器资源：**

* 确保足够的 RAM（最低 1GB，最好 2GB 以上）
* SSD 存储提供比传统驱动器更好的数据库性能

## 主机相关说明[​](#hosting-specific-notes "直接链接到 主机相关说明")

某些主机和 CDN 需要进行配置，才能让 POS 访问 WooCommerce REST API：

| 主机 / 服务       | 问题                                                                        | 修复                                                                                           |
| ----------------- | --------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| **GoDaddy**       | 网站防火墙阻止 `/wp-json/` REST API 调用（错误如 *"Received 'undefined'"*） | `Website Security > Firewall > Settings > Access Control > Allow URL Paths` → 添加 `/wp-json/` |
| **WP Engine**     | 必须显式启用 REST API                                                       | 启用 REST API；如有需要，在其防火墙中将 API 端点加入白名单                                     |
| **Cloudflare**    | 可能阻止 REST API 请求，并可能缓存 API 响应                                 | 检查防火墙规则；添加页面规则为 `/wp-json/*` **绕过缓存**                                       |
| **WordPress.com** | REST API / 产品加载兼容性问题（仅显示 9–10 个产品）                         | 使用自托管的 WordPress.org 以获得完全兼容性                                                    |
| **共享主机**      | PHP 工作进程太少 / 内存太低，无法应对并发 POS 调用                          | 迁移到 VPS 或托管的 WordPress 主机                                                             |

安全插件（Wordfence 等）也可能以类似方式阻止 REST API——有关完整列表和修复方法，请参见 [插件冲突](/zh-CN/support/troubleshooting/plugin-conflicts.md)。

### HTTP 414 — URI 过长[​](#http-414-uri-too-long "直接链接到 HTTP 414 — URI 过长")

大型购物车，或包含在结账 URL 中的访问令牌，可能超过服务器的 URL 长度限制（结账请求使用 `GET`）。这可能与浏览器有关，并因浏览器缓存而加剧。

**解决办法：** 先清除浏览器缓存，然后提高服务器的 URL 长度限制：

* **Apache：** 在 `httpd.conf` 中设置 `LimitRequestLine 65536`
* **Nginx：** 在 `nginx.conf` 中设置 `large_client_header_buffers 4 65536;`
* 如果您没有配置访问权限，请让您的托管服务提供商进行调整。

## 何时寻求帮助[​](#when-to-seek-help "直接链接到 何时寻求帮助")

如果出现以下情况，请联系您的托管服务提供商或 WordPress 开发人员：

* 尽管进行了优化，**服务器负载仍持续 > 8.0**
* 简单操作的**执行时间 > 5000ms**
* 日志中频繁出现 **内存错误**
* **数据库查询持续 > 2 秒**

请向他们提供：

* 从您的日志获取的服务器指标
* 活动插件列表
* 服务器规格（CPU、RAM、存储类型）
* WordPress 和 WooCommerce 版本

## 相关文档[​](#related-documentation "直接链接到 相关文档")

[日志如何访问和解释服务器指标](/zh-CN/support/logs.md)

[结账性能优化支付处理](/zh-CN/support/performance/checkout.md)

[错误代码了解与性能相关的错误代码](/zh-CN/error-codes/.md)

[故障排除一般故障排除指南](/zh-CN/category/troubleshooting.md)