智能导检性能排查

突击一个星期，导检终于优化到一个满意的效果。很难相信容量和规模这么小的一套系统性能如此低下，从代码的规范、数据库和项目的设计以及经验不足的程序员容易挖下的几个坑简单说说。

直观问题

问题表现上看，生产上导检主要三个问题：

• 医生工作站叫号延迟高（10s-30s）。

• 微信消息同步 IIS 假死（一开微信推送站点就挂）。

• 体检入队性能低下（含前置任务时每天体检 150 人都扛不住）

制定短长期方案

这些问题在我接手时已经在几家医院长期存在处于一直安抚中，维护的同事一句改不动无从下手基本上等于研发解决无期。在没有全部 review 导检各个端口代码前，我也没有好的办法。盲从的跟领导和同事开了几个小会。问题全靠推测。

花了两天大致过完项目业务和技术实现后，有了对策：

1.前置任务

从上图可以看到，导检屏和 医生站还有 护士的 Web 端实际上都是空壳，核心业务和实现都在 API 上。那么第一个就是下日志，埋点跟进出问题的业务流转，快速定位到问题（纯体力活）。

2.短期方案

• 导检屏语音叫号的问题，因为技术实现采用轮询，人为控制 5s 一次，语音播报又控制 3s 放完一句，那么刻意去守着，不延迟才怪。实际场景中等一等也勉强 ok，最快的办法就是直接缩短轮询间隔。

• 排查发现万恶之源：static 变量内存常驻。加上对象锁阻塞操作。是设计埋的坑，然后人为其他不规范 coding。使得入队缓慢和医生站卡死是同一个本质问题。在我一直理智要求下，短期不大改设计方向，先把 code 审查优化一遍。

• 微信站点假死，跟我之前授课平台 WCF 挂掉太相似了，批量数据频繁请求导致的，现在已经停了，使用的医院不多，短期不急。

3.长期方案

• 内存式存储要么重新设计要么持久化到其他介质。

• 微信站点假死的问题，要拆分大逻辑，简化数据，降低请求频率。由于受到医院大多内网限制影响。不管是 API 和微信站点通过 redis 共享还是 mq 排队，短期不好做，长期业务发展考虑，必须上（因为压力直接打在外网部署的微信站点，如果 N 家医院公用，崩掉迟早的）。

• 导检屏的轮询设计要改，全平台需要及时消息的地方都上 websocket。语音播报可以根据我后面文章：.NET 技术栈 B/S 架构系统语音交互中提到的方式优化。

  不要用倒计时这么傻的办法，也不要去计算这句话多长要读多久，根据这个时间再次唤醒业务监听。好好监听 SpeechSynthesisUtterance end 事件

实际工作

因为快速过一遍代码，问题太多了，所以我大致判断不用做完长期全部实现，系统稳定和效率都会提升。我甚至怎么重构导检全家桶都有雏形了。但是实操当中还要照顾到 Leader关心的经济效益。最终重点处理了几个问题：

代码优化

• 数据库操作优化。禁止循环体内部操作 db，批量上 sqlbulkcopy，Linq 语句用不到的字段不 Select（实际上对内存区别不大）。

• 内存式存储导致的同一引用对象脏数据 List 索引错误，受序列化和反序列化影响用深拷贝反而比优化前效率更低。做了 request 重试机制短期解决。

• 代码优化。不带顺序要求的队列可以用并行就改并行。冗余代码全部干掉。不改业务结果前提，全部优化代码逻辑。

• 算法优化。循环体内频繁操作对象，先在外层统一查出缩小范围。能抽象成全局逻辑结果的数据，一次性处理好不需要每次都在逻辑内部计算。上 sql 语句简化了一个 6000+指数级频繁运算。

设计优化

同事上了一个微信站点数据请求方式的优化，实际上是把每次数据同步请求（api 数据和微信数据库间）削峰成了按 3s 间隔定时同步。我人为还不是最终实现，但是在当下使用规模和业务量，基本不会批时间做进一步方案了。

在代码优化和部分实现改动达到预期后，导检的优化也 可以被叫停了。

小结

但是我想总结说说问题的本质原因。

• 行政管理。公司的行政管理压力过大，很容一导致员工宁愿不做事，也不犯错。僵化的体制出不了能人。员工积极性几乎为 0，那么剩下的就是相互甩锅、懒政、不作为、问题响应和处理效率低下。管理不够灵活人性化，精打细算的公司出精打细算的员工。

• 项目管理。项目管理方面不具有前瞻性，已知的项目前置管理混乱动工推迟到一个月后，发布紧追在一个半月。不具备技术性。典型我说的 3 个月压缩成 1 个月，最后 1 个半月强上，半年稳定那种。

• 人员流动。行政管理的高压加上项目管理的混乱，导致人员流动非常大，项目的技术实现维护和交接就会直接受影响。程序员的水平得不到保障。摊子越做越烂谁都懒得扶了。

• 问题没有暴露就没有投入。