您询问了一些建议，所以我将分享我的关于测试欢乐频道性能的一般策略。我想这并不是您问题的完整答案，我可能不会告诉您任何您不知道的事情，但我希望这将帮助您找到一个您满意的答案。
出于以下几个原因，请尽量不要花费太多时间“测试整个系统”：

• 首先，测试整个系统必须包括测试底层配置，如CPU内核数量、机箱中使用的网卡以及内核级软件，如TCP/IP堆栈。您通常无法控制这些配置，因此无法以任何方式优化它们。
• 第二，整个系统的性能将严重依赖于机器上运行的辅助代码。如果系统管理员决定"nice“我的Mirth进程，或者使用该机器来托管SQL服务器，这将对系统产生影响，而我（再次）无法控制。
• 第三，也是最坦率的，我发现“整个系统的性能”是管理层在系统设置期间询问的问题，这样他们就可以得到一个成本估计;但他们知道他们得到的只是一个 * 估计 *。您尽可能使用测试指标来为初始硬件配置给予一个很好的猜测，但每个人都知道，实际上是生产性能指标将推动以后的配置成本。

确保您构建了可测试的通道。我发现，当源和目的地可以更改为“Channel Reader”和“Channel Writer”而不更改消息处理时，测试通道会容易得多。一种看待这一点的方式是，您不打算彻底修改Mirth的MLLP堆栈或Java的TCP堆栈，因此只需从您的测试中删除这些东西。
我保留了一个有用的测试消息源。我在网络驱动器上有几个文件，其中有大约100条消息，用于测试我多年来在HL 7接口上遇到的令人讨厌的边缘情况。我编写了一个小型的Mirth通道，它从文件中读取这些消息，并以最快的速度输出副本。通过在通道的目标端打开“Queueing”，我可以将大量的测试消息排队，准备发送到我想要测试的通道。过去，我花时间构建了一个类似于假EMR的测试接口，以吐出随机构建的消息，但与从测试文件中吐出相同消息的副本相比，似乎没有任何优势。
最后，也是最重要的一点是，使用与测量生产示例性能相同的指标来测量测试示例的性能。如果您关心的唯一生产指标是“每秒消息数”，那么这就是您需要在测试机上测量的指标。如果内存占用是生产中的一个问题，那么您还需要测量测试环境中的内存使用情况，当您对测试示例进行更改，使一个重要指标减少10%时，您需要确保您的管理层在将该更改应用到生产环境之前知道这一点。
请注意，获取这些指标可能很困难，因为Mirth不包含监视其自身性能的好工具。Mirth Jmeter 板是监视错误或崩溃的好地方，但它不是查找性能数据的好地方。在我的测试过程中**，我确保使用系统管理员将用于监视生产示例性能的任何资源监视工具**。除此之外，我还使用手动过程来测试性能：如果我想计算每秒的消息数，我会发送一批消息，并查看第一条和最后一条消息的时间戳。如果我想了解Mirth通道的CPU负载，我会使用Windows性能监视器或posix 'top'命令。