Cha*_*ith 3 jmeter performance-testing mirth
Mirth Connect 是一款设计用于处理消息流的软件,它具有内置支持,特别是处理 HL7 消息,因此该软件广泛用于医疗保健应用程序中的接口。多年来,我发现 Mirth 软件遇到性能问题,主要是由于消息随着时间的推移而累积,以及在快速连续接收大量消息负载的情况下造成的。
Mirth 具有基于通道的架构,如果我们能够通过某种方式测试 Mirth 通道的性能并获取其性能的 JMeter 统计数据,那就太理想了。由此,我们可以收集必要的信息来优化通道变压器并相应地设置净化例程。
然而,互联网上几乎没有关于这方面的信息,即如何使用 JMeter 测试 Mirth 通道。斯里兰卡的一个团队早在 2013 年就在这个领域做了一些研究,我在下面找到了他们的发现和成就: http://pragmatictestlabs.com/2016/10/09/performance-testing-healthcare-application-hl7-jmeter/
然而,这是非常具体的,这里的输出是他们提取的 JSon 对象,但是在 Mirth 中我们可以有各种形式的输出,并且需要有更好的方法来做到这一点。一个重要的收获是输入,即输入是通用的,我们可以使用 JMeter 生成 HL7 消息并将它们传递给 Mirth,这很棒,但是如何捕获一般响应,如果有一种方法可以读取 Mirth,那就太理想了通过 JMeter 的仪表板,所有输出统计信息都在那里,只需读取它们即可。
我有一个应用程序,Mirth 读取 ADT 和 RDE 的 HL7 消息,并相应地创建一个具有适当内容的文本文件,并将其放置到共享位置。然后应用程序读取文件并向用户显示信息。
我想在这里做两个性能测试
我可以执行第一个操作,因为我可以使用 JMeter 生成 HL7 消息,并且可以让 JMeter 读取应用程序或数据库中的输出。问题在于第二个,我可以用一般的方式来做到这一点吗?
您征求建议,因此我将分享我的 Mirth 频道性能测试的总体策略。我怀疑这不会是您问题的完整答案,我可能不会告诉您任何您还不知道的事情,但我希望这会帮助您找到您满意的答案。
由于以下几个原因,尽量不要花费太多时间“测试整个系统”:
确保您构建的渠道具有可测试性。我发现,当源和目标可以更改为“通道读取器”和“通道写入器”而不更改消息处理时,测试通道会容易得多。看待这个问题的一种方法是,您不会彻底修改 Mirth 的 MLLP 堆栈或 Java 的 TCP 堆栈,因此只需从测试中消除这些东西即可。
我保留了有用的测试消息来源。我的网络驱动器上有几个文件,其中包含大约一百条消息,用于测试多年来我在 HL7 界面上遇到的令人讨厌的边缘情况。我编写了一个小型 Mirth 通道,它从文件中读取这些内容并尽快输出副本。通过在该通道的目标端打开“排队”,我可以将大量测试消息排队,准备发送到我想要测试的通道。过去,我花时间构建了一个测试界面,它的作用就像一个假 EMR,以喷出随机构造的消息,但与仅从我的测试文件中喷出相同消息的副本相比,似乎没有任何优势。
最后,也是最重要的一点,使用与衡量生产实例性能相同的指标来衡量测试实例的性能至关重要。如果您关心的唯一生产指标是“每秒消息数”,那么这就是您需要在测试盒上测量的指标。如果内存占用是生产中的一个问题,那么您还需要测量测试环境中的内存使用情况。当您对测试实例进行更改导致某个重要指标降低 10% 时,您需要确保管理层了解这一情况,然后再将该更改推入生产环境。
请注意,获取其中一些指标可能很棘手,因为 Mirth 不包含监控其自身性能的良好工具。Mirth 仪表板是关注错误或崩溃的好地方,但不是查找性能数据的好地方。在测试过程中,我确保使用系统管理员将用来监视生产实例性能的任何资源监视工具。除此之外,我使用手动过程来测试性能:如果我想计算每秒消息的数量,我会发送一批消息并查看第一条和最后一条消息的时间戳。如果我想了解 Mirth 通道的 CPU 负载,我可以使用 Windows 性能监视器或 posix 'top' 命令。
| 归档时间: |
|
| 查看次数: |
1136 次 |
| 最近记录: |