放射AI软件的系统效率提升

放射

放射的基本框架

 

每一个服务器内的服务都采用上面统一的结构组成。

 

测试环境的全流程耗时统计

	全流程	等待拉取数据	PACS模块接收数据	后端处理	算法排队	算法模块计算
平均耗时	950s	630s	19s	27s	189s	85s
百分比		66%	2%	3%	20%	9%

 

数据拉取模块

整体结构图

 

现有方案的时间消耗分析（以下以默认配置进行说明）

Find periodic check → db (3 mins)

Move periodic check → db (1 min)→ delay(10 mins)

(receive dicom, compress dicom, seconds level ingore)

整体延时的典型值为10-11分钟。（服务器的时钟不准会影响该值）

 

新设计图（初稿）

新设计逻辑讲解

Find周期查询pacs，如果一个studyUID的图像数量在下一次查询时保持不变，我们认为pacs已经接收图像完成。（注意：pacs自己也无法知道图像什么时候传完）

Find和Move采用RabbitMq作为消息交互通道，比周期轮询数据库具有更及时的响应能力和更低的cpu和io消耗

Find查询pacs时，带上原业务后端的过滤条件，不但可以减少ris的对接，而且可以按需获取，而不是批量拉取再过滤放弃（浪费带宽，磁盘IO，磁盘存储和cpu消耗）

数据拉取模块和业务后端的接口，从原来的数据拉取模块基于restful api主动推送，改为采用ＭＱ作为边界，业务后端根据自己的处理能力按需获取

图像压缩后置。现有方案在拉取图像后，立即进行压缩，导致业务后端和算法模块在处理图像时，有一个额外的解压cpu开销（典型值3秒）。新方案修改为算法模块计算完成后，再进行图像的压缩。

 

新设计的最乐观时间分析

Find periodic check (1 min)

if study instance nums keep the same, publish message to (rabbitmq) to Move

最乐观时间大约为1.5分钟（实际时间以医院运行为准）

 

按序列拉取

pacs在测试环境的接收时间为20秒，需要注意的是，测试环境的都是单序列。

典型的study包括（正位片的薄层/和厚层，纵隔窗的薄层/和厚层，定位片），排除体积很小的定位片，常见的有2或4个序列，这里取平均值3.

则正常按study级别接收，约需要60秒。

如果可以按照series进行目标序列的拉取，则只可以节省40秒。

业务后端

后端从接收数据到向算法模块发送请求的平均时间为1分30秒(和层厚有关系，这个是厦大数据的平均时间)。主要做2件事，1是数据归档，2是序列筛选。主要耗时是数据归档。

数据归档是需要一张一张读取DICOM，然后将相同的seriesUID的图片放到同一个文件夹下，同时将一些关键头信息(病人信息，检查信息，序列信息，图片信息等)存入数据库中。

还需要做一些容错处理，将同一个序列下的重复图片删掉(instanceNumber相同的)，图片像素不一致的删掉。

可以调整的地方：

1. 归档功能直接放到pacsInterface中处理，pacsInterface在接收数据时，本身也会解析DICOM头信息，因此可以直接按照序列归档，同时将头信息保存到数据库中。就向PACS服务器做的一样。

算法工程

CT肺小结节取消转float16的操作，平均每例减少10秒。

 

前端UI

前端性能优化

基于nginx的dicom下载性能 （提速28%，减少4个核的cpu使用）

图像采用无损压缩之后，体积减少接近50%，页面加载速度减少一半。（100M带宽，1100层CT，压缩前加载需要55秒，无损压缩后只需要26秒）

运维/运营模块

脱敏打包

主要设计图（省略了次要逻辑）

 

效率改进

LRU CACHE: 采用lru_cache减少体积估算的２次重复计算（由于lru_cache不支持list的输入，因此，只能对db的query进行缓存）

Process Pool: 采用进程池对图像进行脱敏（脱敏需要cpu资源，因此选择进程而不是线程。采用pool可以重复利用进程，减少不断开启进程的消耗）

Query DB Necessary: 数据库只索要必要的数据（过去使用db，简单粗暴，将db的整个document拉过来，对于study这种以M为单位的document，只拉取需要的字段，能加速不少）

Memory Filesystem: 脱敏后，打包前的dicom图像输出在内存文件系统中，可以减少磁盘IO消耗

Only Archive: dicom图像无法通过传统压缩算法减少体积，因此，只需要打包，减少了打包和解包的cpu消耗

 

 

OCR Server

首先感谢插件客户端的去重处理

插件在GUI截图后，会对图像做hash计算，如果发现图像没有改变，则不发送图像到OCR Server中，这大大减轻了OCR Server的压力。

使用integer类型的fast模型取代float类型的best模型

过去为了追求最佳的识别率，一直采用best模型，甚至采用了融合模式（多模型）。

后面发现，基于integer的fast模型，和基于float的best模型，在ocr识别率几乎一样，因此，现在默认选择fast模型。

fast模型比best模型能节省1/2 ~ 2/3 的运行时间。

 

基础

数据库

凡是需要find的表字段，一定要配置索引