Mirth Connect是一种设计用于处理消息流的软件，并且具有内置的支持，尤其是处理HL7消息，因此该软件被广泛用于医疗保健应用程序中的接口。多年来，我已经看到Mirth软件遇到性能问题的主要原因是消息随着时间的推移逐渐积累，并且在这种情况下，该软件连续快速接收大量消息。
Mirth具有基于通道的体系结构，如果有某种方法可以对Mirth通道进行性能测试并获得其性能的JMeter统计信息，则它是理想的选择。因此，我们可以收集必要的信息以优化通道变压器，并据此设置清除程序。
但是，在Internet上，关于此区域的信息很少甚至没有，这就是人们可以使用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消息，并相应地创建带有适当内容的文本文件，并将其放置到共享位置。然后，应用程序读取文件并将信息显示给用户。
我希望在此处进行两项性能测试1.测量整个系统花费的时间以及从消息到达到用户可用信息的负载量如何变化2.测量信道花费多少时间，以及随着负载的增加如何执行]
我可以做第一个，因为我可以使用JMeter生成HL7消息，并且可以让JMeter读取应用程序或数据库中的输出。问题出在第二个问题上，我可以用一般的方式做到这一点吗？我衷心感谢您的建议和指导，谢谢。
由于多种原因，
尽量不要花费太多时间来“测试整个系统”：
建立可测试性的渠道
。我发现，当源和目标可以更改为“ Channel Reader”和“ Channel Writer”而不更改消息处理时，测试通道要容易得多。一种看待这种情况的方法是，您不会检修Mirth的MLLP堆栈或Java的TCP堆栈，因此只需从测试中消除这些问题即可。我保留有用的测试信息的来源
。我在网络驱动器上有几个文件，这些文件中有大约一百条消息，用于测试多年来在HL7接口上遇到的令人讨厌的边缘情况。我写了一个小的Mirth频道，该频道从文件中读取这些内容，并尽可能快地弹出副本。通过在该通道的目标端打开“排队”，我可以将成千上万的测试消息排队，这些消息准备发送到我要测试的通道。过去，我花时间来构建一个测试界面，该界面的作用类似于假冒的EMR，以散发出随机构造的消息，但是与仅从测试文件中散发相同消息的副本相比，似乎没有任何优势。最后，也是最重要的一点，至关重要的是，使用与测量生产实例的性能相同的度量来测量测试实例的性能
。如果您关心的唯一生产指标是“每秒消息”，那么这就是您需要在测试箱上测量的指标。如果在生产中需要考虑内存占用量，则还需要在测试环境中测量内存使用情况。当您对测试实例进行更改以使重要指标降低10％时，您需要确保管理层知道该更改，然后再将其应用到生产中。请注意，获取某些指标可能很棘手，因为Mirth不包含监视其自身性能的良好工具。 Mirth仪表板是监视错误或崩溃的好地方，但不是查找性能数据的好地方。在测试期间我确保使用sysadmins用来监视生产实例性能的任何资源监视工具
。除此之外，我使用手动过程来测试性能：如果我想每秒计算一条消息，那么我将发送一批消息，并查看第一条消息和最后一条消息的时间戳。如果我想了解Mirth通道的CPU负载，请使用Windows性能监视器或posix'top'命令。