DICOM：基于JMeter+dcm4che2测试PACS服务器性能的解决方案（续篇）

背景：

前一篇博文通过扩展JMeter的java请求，结合dcm4che2现有的工具包dcmsnd.bat实现了简单的测试DICOM服务器C-STORE SCP性能的尝试。由于借用了现有的dcmsnd.bat命令行工具，会有诸多的局限性，比如：

1）必须构造命令行中的参数，才能调用dcmsnd.bat，操作多此一举
2）无法准确跟踪一张图像上传完成后的准确时间
3）既然要模拟海量用户并发，需要准备对应的数量的文件，无法通过自动生成dcm的三级UID来自动生成海量测试文件。

针对上述情况，本篇博文在剖析dcm4che2的dcmsnd工具源码的基础上，给出了自己的DcmSend类，通过该类可自由控制dcm文件发送，与此同时可通过修改单一文件的各级UID来自动模拟出海量dcm文件，提高了测试效率和准确性。下面就给出具体过程。

dcm4che2介绍：

相较于之前常用的dcmtk和fo-dicom，在dcm4che中对于DICOM标准的实现更全面一些，出现了部分之前少有提及的概念，但不必担心，这些新的概念都是对以往概念的总结和归纳 。在dcmsnd.bat工具包源码中用到的几个新概念主要是DICOM3.0标准第15部分，这里主要介绍附录H中的几个核心概念：
1）Device：这里指的是从服务概念来划分的，并不一定指的是物理上的一台设备，有可能是多台设备（比如PET-CT，我也不是很确定？）。但是通常Device可以认为是物理上的一台设备。
2）Transfer Capability：这个在DICOM3.0标准的附录H中被划分成了NetworkAE、NetworkConnection和Transfer Capability三部分，三者的具体关系如下图：

简单来说，Transfer Capability类同于我们之前介绍的Presentation Context（即描述上下文），两者含有的内容是一样的，都是AbstractSyntax+TransferSyntax，即服务类别+编码格式。但两者所描述的范围不同，Transfer Capability是用于描述设备（暂且认为Device对应一台物理设备）的功能，是设备说明书的一部分；而Presentation Context是我们在讲解DICOM网络传输时用到的概念，是在连接建立的握手过程中用于表明连接双方请求的服务和编码格式的，因此从概念上来说Transfer Capability用于宏观，Presentation Context用于微观；Transfer Capability对应于实体（即设备），而PresentationContext对应于服务（即通讯）
总之简单来说，在编码时，可以通过Transfer Capability来设置连接具体交互时的PresentationContext。这一点在DcmSnd.java类的configureTransferCapability，以及的NetworkApplicationEntity.java的makeAAssociateRQ</