Mirth是一个专为处理消息流而设计的软件,它具有内置支持来处理HL7消息,因此该软件被广泛用于医疗保健应用程序中的接口。多年来,我看到Mirth软件经历了性能问题,主要是由于消息随着时间的推移而积累,以及在快速连续接收大量消息的情况下。
Mirth有一个基于通道的架构,如果我们有某种方法可以测试Mirth通道的性能并获得其性能的JMeter统计数据,那么这是最理想的。因此,我们可以收集必要的信息来优化通道转换器,并相应地设置清除例程。
然而,在互联网上,关于这一领域的信息很少,这就是人们如何使用JMeter来测试欢乐频道的。早在2013年,斯里兰卡的一个团队就对这一领域进行了一些研究,我在http://pragmatictestlabs.com/2016/10/09/performance-testing-healthcare-application-hl7-jmeter/下面找到了他们的发现和成就
然而,这是非常具体的,这里的输出是他们提取的JSon对象,但是在Mirth中,我们可以有各种形式的输出,需要有更好的方法来做到这一点。一个重要的结论是输入是通用的我们可以使用JMeter来生成HL7消息并将它们传递给Mirth这很好,但是如何捕获响应一般来说,如果有一种方法可以通过JMeter读取Mirth仪表板,所有的输出统计数据都在那里,这只是读取它们的问题。
我有一个应用程序,在这个应用程序中,Mirth读取ADT和RDE的HL7消息,并相应地创建一个包含适当内容的文本文件,然后将其放到共享位置。然后,应用程序读取文件并向用户显示信息。
我希望在这里做两个性能测试: 1.测量整个系统需要多长时间,以及从消息到达到其信息对用户可用这段时间随负载的变化情况2.测量通道需要多长时间,以及随着负载的增加它是如何完成的
我可以执行第一个操作,因为我可以使用JMeter生成HL7消息,并且可以让JMeter读取应用程序或数据库中的输出。第二个问题是,我可以用一般的方式来做这个吗?我真诚地感谢您的建议和指导,谢谢。
发布于 2019-12-14 01:31:46
你问我的建议,所以我将分享我的性能测试的一般策略的快乐频道。我怀疑这不是你问题的完整答案,我可能不会告诉你任何你还不知道的事情,但我希望这能帮助你找到一个你满意的答案。
出于几个原因,尽量不花太多时间来“测试整个系统”
确保为可测试性构建您的通道。我发现,如果可以将源和目标更改为"Channel Reader“和"Channel Writer”,而无需更改消息处理,则测试通道会容易得多。考虑这一点的一种方法是,您不会彻底检查Mirth的MLLP堆栈或Java的TCP堆栈,因此只需从测试中删除这些内容即可。
I保持一个有用的测试消息源。我在网络驱动器上有几个文件,其中有大约100条消息,用于测试多年来我在HL7接口上遇到的糟糕的边缘情况。我写了一个小的Mirth通道,它从文件中读取这些内容,并以最快的速度输出副本。通过在该通道的目标端打开“排队”,我可以将准备发送到我想要测试的通道的无数测试消息排入队列。在过去,我花时间构建了一个测试接口,它就像一个假的EMR,发出随机构造的消息,但与仅仅从我的测试文件中发出相同消息的副本相比,似乎没有任何优势。
最后,也是最重要的一点,您必须使用与用于度量生产实例的性能相同的度量来度量测试实例的性能,这一点至关重要。如果您关心的唯一生产指标是“每秒消息数”,那么这就是您需要在测试箱上测量的指标。如果在生产环境中需要考虑内存占用,那么还需要测量测试环境中的内存使用情况。如果您对测试实例进行了更改,将重要指标减少了10%,则在将更改推送到生产环境之前,您需要确保您的管理层已意识到这一点。
请注意,获取这些指标中的一些指标可能会很棘手,因为Mirth不包括用于监控其自身性能的好工具。Mirth仪表板是监视错误或崩溃的好地方,但不是查找性能数据的好地方。在测试期间,我确保使用系统管理员用来监视生产实例性能的任何资源监视工具。除此之外,我使用手动过程来测试性能:如果我想计算每秒的消息数,我会发送一批消息,并查看第一条和最后一条消息的时间戳。如果我想了解Mirth通道的CPU负载,我可以使用Windows性能监视器或posix 'top‘命令。
https://stackoverflow.com/questions/59236334
复制相似问题