性能优化与工程取舍：低配服务器和大影像如何不崩

问题引入

医学影像 Viewer 的性能问题通常不是某一行代码慢，而是数据规模、内存生命周期和交互频率叠加后的结果。一个 CT 检查可能有几百张 512x512 切片，MPR 会把它们堆成 volume，3D 会再交给 VTK session，Web 上传还会占磁盘，Socket 交互还会持续推图。如果部署在 2 核 4G、3M 带宽的低配服务器上，任何一个环节放任增长都会把系统拖垮。

DicomVision 的性能策略可以概括为：尽量晚地读取像素，尽量小地渲染当前视口，尽量明确地释放缓存，尽量限制公开 Web Demo 的资源生命周期。

背景概念

DICOM 的瓶颈有三类。第一类是 I/O 和解码：读文件、解压 PixelData、转换颜色空间。第二类是内存：多张切片堆叠成 volume 后，很容易从几十 MB 变成几百 MB。第三类是渲染和网络：每次窗口调整、滚轮、拖拽、窗宽窗位都可能触发一帧图片生成和推送。

服务端渲染的优势是可以集中使用 Python、NumPy、SciPy、VTK，前端压力小；代价是服务器承担了更多 CPU、内存和磁盘压力。公开 Web Demo 时，这个代价会放大，因为用户上传的数据可能很大，也可能不主动清理。

项目实现

扫描阶段使用 stop_before_pixels=True，避免打开目录时解码所有像素。真正渲染时再进入 DicomCache，使用 LRU 思路保存最近用到的 Dataset 和 source_pixels。缓存同时受条目数和字节数限制，超过后淘汰最久未使用的项。Tag 查看场景使用 defer_size，避免较大的元素一次性读入。

视口渲染受前端真实尺寸控制。后端不需要给一个 500x500 的视口渲染 4096x4096 的图片。交互阶段可以走 fast preview，松手或稳定后再补质量更好的最终帧。Socket.IO 只把当前 viewId 订阅的图像推给对应连接，而不是广播给所有用户。

桌面端还要注意 Object URL 生命周期。前端收到二进制图片后会创建 blob: URL，如果不释放，长时间滚动会把浏览器进程内存堆高。Web Demo 还需要上传目录自动清理，PACS 下载缓存也应该有生命周期。对于低配服务器，自动清理不是锦上添花，而是公开访问的基本防线。

关键函数表

策略	对应实现	解决的问题
header-only 扫描	pydicom.dcmread(..., stop_before_pixels=True)	加快目录加载，降低初始内存
像素按需解码	dicom_cache.get 中访问 dataset.pixel_array	只为当前视口读像素
LRU 缓存	OrderedDict.move_to_end、popitem(last=False)	避免重复读文件，同时限制内存
Tag 延迟读取	dcmread(..., defer_size=1024)	查看元数据时避免大元素立即加载
视口尺寸渲染	setSize 后按 canvas 大小输出	避免无意义大图
VTK 单线程会话	renderer executor/session	避免 3D 上下文竞争
上传目录清理	定时后台任务	防止 Web Demo 磁盘被填满

自绘图表

风险	2 核 4G 3M 服务器上的表现	建议控制项
大文件上传	磁盘快速增长，上传时间长	上传大小限制、目录定时清理
多用户 3D	CPU 和内存竞争明显	登录、并发限制、禁用高成本 Demo
MPR 大 volume	float32 volume 占数百 MB	缓存上限、释放未使用序列
Socket 高频推图	带宽和 CPU 同时消耗	预览帧、节流、只推当前视图
PACS 下载缓存	长时间运行后磁盘堆积	下载缓存 TTL 和手动清理入口

小结

DicomVision 的性能优化不是单点技巧，而是一组工程边界：扫描不解码，解码走缓存，渲染按视口，交互可预览，资源要清理，公网 Demo 要限额。对于低配服务器，最重要的不是追求所有功能都开放，而是明确哪些资源会增长，并给它们设置上限和生命周期。