我们使用 mirth connect 将消息从 hl7 转换为文本，并将转换后的消息存储到 azure sql 数据库。我们目前的性能是每小时 45000 条消息。
机器配置是 8 GB RAM 和 2 核 CPU。分配给 mirth 的内存是 -XMS = 6122MB
我们不知道在上述配置下 Mirth 的性能参数是什么。有人知道 Mirth connect 的性能基准吗？
【问题讨论】：
标签： mirth
我建议查看 3.4 及更高版本中的 Max Processing Threads 选项。它可以在源设置（源选项卡）中进行配置。默认情况下，它设置为 1，这意味着在任何给定时间，只有 一个 消息可以通过通道的主处理线程进行处理。这对于某些消息顺序至关重要的接口很重要，但显然它会限制吞吐量。
请注意，无论客户端发送您的频道消息也，都需要重新配置以并行发送多条消息。例如，如果您有一个单线程进程通过 TCP/MLLP 依次发送通道消息，则增加最大处理线程数不一定有帮助，因为客户端仍然是单线程的。但是，例如，如果您让 10 个客户端同时发送到您的频道，那么您肯定会获得增加最大处理线程数的好处。
如果您的源连接器是轮询类型，例如文件读取器，您仍然可以通过打开源队列并增加最大处理线程数来从中受益。当启用源队列并且您有多个处理线程时，将启动多个队列消费者并同时从源队列中读取和处理。
另一件事是目的地排队。在高级（扳手图标）队列设置中，有一个类似的选项可以增加目标队列线程的数量。默认情况下，当您启用目标队列时，只有一个队列线程以 FIFO 序列处理消息。同样，有利于消息顺序，但会妨碍吞吐量。
如果您确实需要订购消息并且希望最大化并行吞吐量（AKA 也有你的蛋糕并吃掉它），你可以使用线程分配变量结合多个目标队列线程。这允许您保留具有相同唯一标识符的消息之间的顺序，而与不同标识符有关的消息可以同时处理。一个常见的用例是为此使用患者 MRN，以保证给定患者的所有消息都按照接收顺序进行处理，但纵向跨不同患者的消息可以同时处理。
【讨论】：
我们正在使用 AWS EC2 4c.4xlarge 实例来测试基本概念证明性能限制。我们得到了大约 50 msgs/sec，在 cpu/memory/network/disk io/db io 等方面没有明显的瓶颈。想要将限制推得更高。如果有的话，请分享你的观察。
【讨论】：
我们运行相同的流程。欢乐 -> Azure SQL 数据库。我们现在正在进行性能测试，一直停留在 12 - 15 条消息/秒（43000 - 54000 条/小时）。
我们已在每个频道上运行测试并发现： 1 通道源：文件阅读器 -> 目标：Azure SQL DB 大约是每小时 36k 2 通道源：文件阅读器 -> 目标：Azure SQL DB 约为每小时 59k 3 通道源：文件阅读器 -> 目标：Azure SQL DB 大约每小时 80k
我们在 1 个通道上的源和目标都添加了多线程 (2,4,8)，但性能没有提高。 Mirth 在 8GB 内存和 2 个核心上运行，堆大小设置为 2048MB。
现在，我们将在与 C4.4xlarge 类似的“硬件”上运行一些测试，该硬件在 Azure 中是 16 核和 32GB 内存。还有 200GB 的 SSD 可用。
我们的目标是每个频道每小时 10 万条消息。
【讨论】：