负载测试：检查清单和失败

负载测试的系统化方法：从令牌故障到稳定指标

后端作为前端与外部服务之间的代理，通过opcache缓存访问令牌。在高负载下，多个并行请求同时检测到令牌过期并尝试刷新。旧令牌在缓存中覆盖了新令牌，导致403错误。

解决方案：我们为令牌刷新添加了锁，并将缓存移至集群化memcached，以实现跨进程的统一状态。在Postman中使用并行请求进行测试，确认竞态条件已消除。

优化前指标：响应时间呈指数增长，成功率在300 RPS时降至90%以下。优化后：成功率100%，5xx错误率<0.05%，在226 RPS下平均响应时间99-104毫秒。

后端准备：优化清单

在进行负载测试（LT）前，后端开发人员遵循系统化清单。这能最大程度减少代码和基础设施层面的瓶颈。

数据库优化

• 为WHERE和JOIN子句中的所有字段建立索引。
• 分析慢查询的EXPLAIN结果。
• 主从复制，连接池（如pgbouncer或等效工具）。

缓存

• 使用Memcached处理重复数据。
• 在Varnish或nginx中缓存HTTP响应。
• Twig模板缓存。

异步处理

• 使用RabbitMQ或Redis队列处理后台任务。
• 将邮件发送、PDF生成等任务卸载到后台作业。

PHP代码

• 消除N+1查询。
• 优化循环，避免深度递归。
• 使用unset()释放大型对象的内存。

基础设施

• php-fpm：pm.max_children > 100，pm.max_requests = 500。
• 使用MinIO进行文件存储。
• 基于CPU/RAM的Kubernetes HPA。
• 使用速率限制器（nginx或Traefik）进行节流。

前端：减少传入负载

前端生成主要流量。此处的优化可将后端RPS降低30-50%。

• 静态资源：使用nginx缓存JS/CSS/图像。
• 客户端API缓存：使用localStorage或memcached缓存不常变化的数据（如目录、配置）。
• 分页：使用limit/offset或无限滚动，而非全量数据加载。
• SSG/ISR：使用Next.js进行静态页面渲染。
• SSE/Webhooks：用推送通知替代轮询。

负载测试工作流程

LT对于更改服务器逻辑、缓存或数据库的功能是强制性的。在用户负载最低的夜间，在预发布/生产环境中进行。

• 规划（提前一周）：负责人+产品经理+DevOps估算目标RPS（N请求/秒）。
• DevOps角色：配置pod（CPU/RAM）、HPA、实时监控。
• 执行：使用k6或类似工具，针对API端点设计场景。
• 监控：使用Grafana（RPS、延迟、错误率）、Graylog记录日志。
• 分析：识别性能下降点，修复瓶颈，重复测试。

成功标准：在目标RPS下，成功率>99%，延迟<150毫秒，并预留20%缓冲。

关键要点

• 进程竞态（如令牌、会话）仅在并行负载下显现。
• 使用集群化缓存（memcached）替代本地opcache可防止竞态条件。
• 在类生产环境中进行LT：数据库复制、外部服务。
• DevOps参与：在测试期间动态调整资源。
• 前端优化比后端修复更能有效减少负载。

成功指标与基准

修复后Grafana示例：

| 指标 | 平均值 | 峰值 | 目标 |

|--------|---------|------|--------|

| 成功率 | 100% | 100% | >99% |

| 5xx错误率 | 0.017% | 0.042% | <0.1% |

| RPS | 226 | 321 | 300+ |

| 延迟（毫秒） | 99-104 | 123 | <150 |

在226 RPS下稳定无性能下降。故障点：约450 RPS（100%缓冲）。

对中高级开发人员的建议

• 将LT集成到CI/CD中：合并时自动测试。
• 监控p99延迟，而非仅平均值。
• 测试最坏情况：80%流量集中在单个端点。
• 记录请求ID以便追踪（如Jaeger/OpenTelemetry）。

此方法可在开发阶段识别问题，减少生产环境中的事故。

— Editorial Team