tiku-backend.net/tools/performance/RESULTS-2026-07-30.md

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 的时序观测。