重计算改成多进程,两人同时算不再抢一个核 #133

Open
opened 2026-10-28 06:02:50 +08:00 by Claude · 2 comments
Collaborator

来自 #118 代码体检(体检第 9 条),清单第 14 单。由 Claude 直接实现,不交 Grok。

问题

排盘服务是单进程 ThreadingHTTPServer,纯 Python 重计算受 GIL 限制;JYOTISH_HEAVY_COMPUTE_CONCURRENCY=2 等于两人抢一个核。实测单跑 1.19 s,两路并发各 2.35~2.6 s。

改法

新模块里给 v5 score / block_scan / 报告开进程池,max_workers = 重计算并发数,主文件只薄注册;worker 固定 PYTHONHASHSEED(ERR-111);核算内存。

验收标准

两路并发各 ≤ 单跑 1.3 倍;规范化 JSON 与改前一致;全量 pytest 与基线一致。

规矩

  • 基于 origin/staging,独立工作树 codex/*;只改这一件事。
  • BUG 号开工时按 docs/BUG_HISTORY.md 全文件取最大号 +1。
  • 同时改 frontend/src/app/(app)/page.tsx 的单按清单顺序串行。
  • 体检报告:docs/research/code_health_audit_2026_10_28.md(staging a31b6dda3)
来自 #118 代码体检(体检第 9 条),清单第 14 单。**由 Claude 直接实现,不交 Grok。** ## 问题 排盘服务是单进程 `ThreadingHTTPServer`,纯 Python 重计算受 GIL 限制;`JYOTISH_HEAVY_COMPUTE_CONCURRENCY=2` 等于两人抢一个核。实测单跑 1.19 s,两路并发各 2.35~2.6 s。 ## 改法 新模块里给 v5 score / block_scan / 报告开进程池,`max_workers` = 重计算并发数,主文件只薄注册;worker 固定 `PYTHONHASHSEED`(ERR-111);核算内存。 ## 验收标准 两路并发各 ≤ 单跑 1.3 倍;规范化 JSON 与改前一致;全量 pytest 与基线一致。 ## 规矩 - 基于 origin/staging,独立工作树 `codex/*`;只改这一件事。 - BUG 号开工时按 `docs/BUG_HISTORY.md` 全文件取最大号 +1。 - 同时改 `frontend/src/app/(app)/page.tsx` 的单按清单顺序串行。 - 体检报告:`docs/research/code_health_audit_2026_10_28.md`(staging `a31b6dda3`)
Claude added the agent/试点agent/排队 labels 2026-10-28 06:02:57 +08:00
Author
Collaborator

已改完,推上 staging(8d1cb4a5,同一批),正在部署。

  • 排盘服务以前只有一个进程,重计算闸门虽然允许两路同时跑,实际上两路在抢一个核。现在最重的三类计算(生时校正打分、24 小时分块扫描、长报告参考)放进两个独立的工作进程。
  • 本机真起服务、经 HTTP 实测校正打分:
单独一路 两路同时(每路) 倍数
改前(单进程) 4.5 秒 7.0 秒 1.56 倍
改后(两个工作进程) 4.74 秒 5.01 / 4.58 秒 1.06 倍

单子要求两路同时每路不超过单跑的 1.3 倍,达标。

  • 结果不变:打分结果除了本来就随进程变化、不参与任何判断的特征指纹之外逐项相同;长报告参考经工作进程生成的 147 万字 markdown 与原来逐字节相同。
  • 内存:两个工作进程各约 75 MB,合计多约 165 MB,4 GB 主机够用。工作进程崩溃时这次请求改在主进程算、进程池在后台自动重建;需要时设 JYOTISH_HEAVY_COMPUTE_PROCESSES=0 就能关掉。
  • 检查:Python 快速门全部 Python 步骤通过;新增 6 条测试。记为 BUG-1493。不需要真机看。部署好了我再说。
<!-- agent:claude review sha=8d1cb4a5 verdict=pass staging=12eb7018ecfb35c3bec0c25bd74efd6ba9a65816 checklist=- --> 已改完,推上 staging(`8d1cb4a5`,同一批),正在部署。 - 排盘服务以前只有一个进程,重计算闸门虽然允许两路同时跑,实际上两路在抢一个核。现在最重的三类计算(生时校正打分、24 小时分块扫描、长报告参考)放进两个独立的工作进程。 - 本机真起服务、经 HTTP 实测校正打分: | | 单独一路 | 两路同时(每路) | 倍数 | | --- | --- | --- | --- | | 改前(单进程) | 4.5 秒 | 7.0 秒 | 1.56 倍 | | 改后(两个工作进程) | 4.74 秒 | 5.01 / 4.58 秒 | 1.06 倍 | 单子要求两路同时每路不超过单跑的 1.3 倍,达标。 - 结果不变:打分结果除了本来就随进程变化、不参与任何判断的特征指纹之外逐项相同;长报告参考经工作进程生成的 147 万字 markdown 与原来逐字节相同。 - 内存:两个工作进程各约 75 MB,合计多约 165 MB,4 GB 主机够用。工作进程崩溃时这次请求改在主进程算、进程池在后台自动重建;需要时设 `JYOTISH_HEAVY_COMPUTE_PROCESSES=0` 就能关掉。 - 检查:Python 快速门全部 Python 步骤通过;新增 6 条测试。记为 BUG-1493。不需要真机看。部署好了我再说。
Claude added agent/部署中 and removed agent/排队 labels 2026-10-28 14:29:41 +08:00
Author
Collaborator

已部署到 staging(12eb7018,现在线上是包含它的 537beb29),@jesse 可以看一下了。 门禁、迁移、部署全部成功;登录页正常,未登录访问账户接口被拒绝(401)。

这单是后台提速(重计算分到多个进程),界面不变,没有专门的真机清单。顺手验一下就行:两个人(或两个浏览器)同时生成报告 / 做生时校正,两边都正常出结果、没有明显变慢。

<!-- agent:claude deployed sha=12eb7018ecfb35c3bec0c25bd74efd6ba9a65816 --> **已部署到 staging(`12eb7018`,现在线上是包含它的 `537beb29`),@jesse 可以看一下了。** 门禁、迁移、部署全部成功;登录页正常,未登录访问账户接口被拒绝(401)。 这单是后台提速(重计算分到多个进程),界面不变,没有专门的真机清单。顺手验一下就行:两个人(或两个浏览器)同时生成报告 / 做生时校正,两边都正常出结果、没有明显变慢。
Claude added agent/待真机 and removed agent/部署中 labels 2026-10-29 10:14:53 +08:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: root/Jyotisha#133