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

·  阅读 206

放射

放射的基本框架

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

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

全流程

等待拉取数据

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主动推送,改为采用MQ作为边界,业务后端根据自己的处理能力按需获取

图像压缩后置。现有方案在拉取图像后,立即进行压缩,导致业务后端和算法模块在处理图像时,有一个额外的解压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减少体积估算的2次重复计算(由于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的表字段,一定要配置索引

分类:
后端
标签:
收藏成功!
已添加到「」, 点击更改