放射
放射的基本框架
每一个服务器内的服务都采用上面统一的结构组成。
测试环境的全流程耗时统计
全流程
等待拉取数据
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相同的)，图片像素不一致的删掉。
可以调整的地方：
- 归档功能直接放到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的表字段，一定要配置索引
