Mirth性能基准

Question

我们使用mirth实现从hl7到文本的消息转换，并将转换后的消息存储到azure sql数据库中。我们目前的表现是每小时45000条信息。

机器配置为8 GB RAM和2核心CPU。分配给mirth的内存是-XMS =6122 is

对于上述配置，我们不知道Mirth的性能参数是什么。有人知道Mirth connect的性能基准吗？

Answer 1

我建议查看版本3.4和更高版本中的Max处理线程选项。它可以在Settings (Source选项卡)中进行配置。默认情况下，它被设置为1，这意味着只有一条消息可以在任何给定时间通过通道的主处理线程进行处理。对于某些接口来说，这是很重要的，因为在某些接口中，消息的顺序是最重要的，但显然它限制了吞吐量。

请注意，无论客户端发送什么通道消息，也需要重新配置，以便并行发送多条消息。例如，如果您有一个单线程进程，它依次通过TCP/MLLP发送通道消息，增加最大处理线程并不一定会有所帮助，因为客户机仍然是单线程的。但是，例如，如果您站起来10个客户端同时发送到您的通道，那么您肯定会受益于增加最大处理线程。

如果源连接器是轮询类型，就像文件读取器一样，您仍然可以通过打开源队列并增加Max处理线程来从中受益。当启用源队列并具有多个处理线程时，将启动多个队列使用者，并同时从源队列读取和处理所有队列。

另一件事要看的是目的地排队。在高级(扳手图标)队列设置中，有一个类似的选项来增加目标队列线程的数量。默认情况下，当启用目标队列时，只有一个队列线程以FIFO顺序处理消息。同样，对消息顺序有好处，但会阻碍吞吐量。

如果您确实需要对消息进行排序，并希望最大限度地提高并行吞吐量(AKA有您的蛋糕，并且也吃了它)，您可以将线程分配变量与多个目标队列线程结合使用。这允许您保留具有相同唯一标识符的消息之间的顺序，而涉及不同标识符的消息可以同时处理。一个常见的用例是为此使用病人MRN，这样就可以保证每个病人的所有消息都能按照接收到的顺序处理，但是纵向上跨不同患者的消息可以同时处理。

Answer 2

我们正在使用AWS EC2 4c.4xlarge实例来测试概念性能极限的赤裸裸的证明。我们在cpu/内存/网络/磁盘io/db等方面没有明显的瓶颈，我们得到了大约50 msgs/秒。如果有的话，请分享你的意见。

Answer 3

我们运行相同的过程。-> Azure数据库。我们现在正在进行性能测试，并且一直停留在每秒12 - 15条消息(每小时43000到54000条)。

我们对每个通道进行了测试，发现如下:1通道源:文件读取器->目的地: Azure约为每小时36k，2通道源:文件阅读器->目的地: Azure约为每小时59k

我们增加了多线程(2,4,8)到源和目的地在一个通道，没有任何性能提高。Mirth运行在8GB mem和2个堆大小设置为2048 to的核心上。

我们现在将在类似的“硬件”上运行一些测试，比如C4.4xlarge，Azure中有16核和32 16的mem。也有200 as的SSD可用。

我们的目标是每个频道每小时100000条信息。