49 lines
3.1 KiB
Markdown
49 lines
3.1 KiB
Markdown
# 2026-07-30 本机并发基线
|
||
|
||
## 结论
|
||
|
||
- 默认 `mixed` 读流量在 10 秒短测中完整通过 5000 RPS；6000 RPS 开始出现少量 dropped iterations，8000 RPS 已明显饱和。因此这台机器上的单实例短时安全线应按 **5000 RPS 以下**理解，而不是把 8000 RPS 当成容量。
|
||
- 每个请求都执行 PostgreSQL + Redis 依赖检查的 `ready` 场景，2000 RPS 完整通过；4000 RPS 完成 39,969/40,000 次目标迭代，出现 32 次 dropped iterations 与 8 次 503，严格门槛未通过。因此依赖重型场景的已验证短时安全线是 **至少 2000 RPS，4000 RPS 已在边缘**。
|
||
- 这些数字是本机、小种子数据、10 秒短测结果，不是生产 SLA 或长期持续容量。
|
||
|
||
## 环境
|
||
|
||
- Mac17,3，10 个逻辑 CPU，16 GiB 内存，macOS 26.5.2，arm64。
|
||
- .NET SDK 10.0.301，ASP.NET Core Runtime 10.0.9，Release 单实例。
|
||
- PostgreSQL 与 API 在本机运行；Redis 7 运行在 Docker `tiku-redis`。
|
||
- k6 运行在 `grafana/k6:latest` Docker 容器。
|
||
- API 业务限流关闭，后台任务关闭，默认日志级别调到 Warning，避免测到限流器或日志终端吞吐。
|
||
- 租户使用 `demo-crm-school`，目录响应为小数据集。
|
||
|
||
## 结果
|
||
|
||
### 混合读流量
|
||
|
||
流量比例为 70% 热目录、20% 唯一查询参数的冷目录、10% PostgreSQL + Redis readiness。
|
||
|
||
| 目标 RPS | 完成迭代 | 错误率 | dropped | p95 | p99 | 判定 |
|
||
| ---: | ---: | ---: | ---: | ---: | ---: | --- |
|
||
| 1000 | 10,001 | 0% | 0 | 1.31 ms | 1.97 ms | 通过 |
|
||
| 2000 | 20,001 | 0% | 0 | 1.32 ms | 6.54 ms | 通过 |
|
||
| 4000 | 40,001 | 0% | 0 | 1.43 ms | 6.38 ms | 通过 |
|
||
| 5000 | 50,001 | 0.004% | 0 | 7.93 ms | 62.29 ms | 通过 |
|
||
| 6000 | 59,859 | 0% | 142 | 5.58 ms | 29.00 ms | 未通过：开始掉迭代 |
|
||
| 7000 | 69,776 | 0% | 226 | 32.27 ms | 84.21 ms | 未通过：掉迭代 |
|
||
| 8000 | 62,186 | 0.01% | 17,815 | 936.11 ms | 1.06 s | 饱和 |
|
||
|
||
### PostgreSQL + Redis 全请求依赖检查
|
||
|
||
4000 RPS 的独立复测结果：
|
||
|
||
- 39,969 次完成迭代，实际约 3957 RPS。
|
||
- 8/39,971 HTTP 请求失败，错误率 0.02%；API 日志记录 8 次 readiness 503。
|
||
- dropped iterations 32；p95 19.33 ms，p99 84.07 ms，最大 384.24 ms。
|
||
- PostgreSQL `xact_commit` 增加 79,931，`blks_hit` 增加 23,661，`blks_read` 不变，说明本次数据页全部命中 PostgreSQL shared buffers。
|
||
- Redis `total_commands_processed` 增加 39,989，`rejected_connections` 保持 0，证明 Redis 确实参与了几乎每次请求。
|
||
|
||
对应原始结果位于忽略提交的 `artifacts/performance/20260730-161031-ready-4000rps/`。
|
||
|
||
## 适用边界
|
||
|
||
当前目录数据很小，而且 PostgreSQL 页面全在内存中；生产数据量上升后，冷查询、索引质量与返回体大小会显著改变结果。API、PostgreSQL 和 Redis 也在同一台开发机上，会产生资源竞争且没有真实网络延迟。正式容量结论至少还需要：独立发压机、接近生产的数据量、30 分钟以上稳态测试、认证读写场景，以及对 CPU、GC、Npgsql 连接池、PostgreSQL locks/I/O 与 Redis latency 的时序观测。
|