signal-cli-rest-api 项目中的 JSON-RPC 模式性能问题分析与解决

问题现象

在 signal-cli-rest-api 项目从 v0.83 升级到 v0.84 版本后，用户报告了一个严重的性能问题：当使用 JSON-RPC 模式发送消息时，请求处理时间从原来的几秒钟骤增至数分钟甚至半小时，而 Native 模式则保持正常的响应速度。

环境与复现

问题出现在 Docker 容器环境中，x86-64 架构。通过对比测试可以清晰观察到：

• JSON-RPC 模式下，单个发送请求耗时超过 10 分钟
• Native 模式下，相同请求仅需 5 秒左右完成
• 系统日志显示 Java 进程持续占用接近 100% 的 CPU 资源

排查过程

初步分析

开发者首先尝试了以下排查手段：

1. 检查容器日志，未发现明显错误信息
2. 对比不同模式下的性能差异
3. 尝试降级到 v0.83 版本，但遇到数据库兼容性问题

深入诊断

通过技术专家的指导，用户进行了更深入的排查：

1. 使用 strace 跟踪进程系统调用，未发现异常
2. 发现 Java 进程持续高 CPU 占用
3. 直接通过命令行执行 signal-cli 的 JSON-RPC 命令，复现相同问题

关键发现是：JSON-RPC 服务进程在发送消息时陷入某种计算密集型操作，导致请求处理被严重延迟。

根本原因

经过一系列测试和分析，确定问题根源在于：

Signal 账户的本地数据库可能已损坏或包含过多历史数据，导致 JSON-RPC 模式下的消息处理流程出现性能瓶颈。这种问题在 Native 模式下表现不明显，因为两者的实现机制不同。

解决方案

验证有效的解决方法是：

1. 完全清除原有的本地数据存储
2. 重新初始化 Signal 账户链接
3. 重建本地数据库

执行这些步骤后，JSON-RPC 模式的性能恢复正常水平。

经验总结

对于类似问题，建议采取以下排查步骤：

1. 首先确认问题是否特定于某种运行模式
2. 检查系统资源使用情况（CPU、内存等）
3. 尝试简化环境，排除容器编排等外部因素
4. 考虑数据库/本地存储的完整性
5. 必要时重建环境作为最后手段

这个问题提醒我们，在升级类似消息服务时，应当：

• 提前备份关键数据
• 在测试环境验证升级影响
• 监控系统资源使用变化
• 准备好回滚方案

对于 signal-cli-rest-api 用户，如果遇到类似性能问题，建议优先检查本地存储状态，必要时重建环境。