## **简介** 最近完成了针对IRIS医疗版2020.1版本的性能及可扩展性基准测试,重点关注HL7v2的互操作性。本文介绍了在各种工作负载下观察到的吞吐量,并提供了IRIS医疗版用作HL7v2消息传输互操作性引擎时的系统常规配置和调整准则。 基准测试模拟了与实际环境接近的工作负载(详细信息请参见“工作负载说明和方法”部分)。本次测试的工作负载包括HL7v2患者管理(ADT)和生命体征结果(ORU)数据,并包含数据内容转换和路由。 IRIS医疗版2020.1版本可以表明,采用第二代Intel®Xeon®可扩展处理器和Intel®Optane™SSD DC P4800X系列SSD存储的商用服务器,每天的持续消息吞吐量超过23亿条(入站和出站总量),与此前的Ensemble 2017.1 HL7v2吞吐量基准测试相比,扩展性提高了一倍多。 在这些测试过程中,将IRIS医疗版配置为先进/先出(FIFO)顺序,并且在磁盘中完整保存每个入站和出站消息以及消息队列信息。通过持久化消息队列和消息内容,IRIS 医疗版能够在系统崩溃时提供数据保护,并提供完整的历史消息搜索和重新发送功能。 下面将继续介绍配置准则,帮助您选择适当的配置和部署,以充分满足工作负载性能和可扩展性需求。 通过实验结果可以证实,IRIS 医疗版能够满足商用硬件上的极端消息吞吐量需求,并且在大多数情况下支持仅用单个小型服务器可为整个组织提供HL7互操作性服务。 ##![](/sites/default/files/inline/images/images/image-20210120152852-1.gif) **结果概述** 以下三种工作负载代表了HL7互操作性活动的不同方面: **·T1工作负载:**使用HL7消息的简单传递,每条入站消息对应一个出站消息。不需要路由引擎就可以直接将消息从Ensemble业务服务传递到Ensemble业务操作。不使用任何路由规则,也不执行任何消息内容转换。每条入站消息都在数据库中创建了一个HL7消息对象。 **·T2工作负载:**通过路由引擎将入站消息平均分成4个分段,并将其路由到单个出站接口(1对1转换)。对每条入站消息执行一次数据转换,并在数据库中创建两个HL7消息对象。 **·T4工作负载:**使用路由引擎将单独修改的消息路由到四个出站接口中的每一个接口。平均而言,每次转换都会修改入站消息的4个分段(1条入站消息对应4条出站消息,进行4次转换)。对于每条入站消息,将执行4次数据转换,向外发送4条消息,并在数据库中创建5个HL7消息对象。 这三个工作负载是在一个物理48核系统上运行的,该系统有两个Intel®可扩展Gold 6252处理器和两个运行Red Hat Enterprise Linux 8的750GB Intel®Optane™SSD DC P4800X SSD驱动器。测试记录每秒(和每小时)入站的消息数、每秒(和每小时)出站的消息数,以及一天10小时内的总消息数(入站与出站)。此外,CPU利用率是用于衡量既定吞吐量水平下可用系统资源的指标。 ## **可扩展性结果** 表1:该测试硬件配置的四个工作负载吞吐量汇总 ![](https://community.intersystems.com/sites/default/files/inline/images/images/table-1.png) * 包含25%的T1,25%的T2和50%T4的“混合工作负载” ## **工作负载描述及方法论** 测试的工作负载包括HL7v2患者管理(ADT)和生命体征结果(ORU)消息,平均大小为1.2KB,平均14个片段。通过转换大约修改了4个片段(针对T2和T4工作负载)。测试包括48至128个入站接口和48至128个出站接口,通过TCP/IP接收和发送消息。 在T1工作负载中,使用了四个单独的命名空间,每个命名空间有16个接口;T2工作负载使用了三个命名空间,每个命名空间有16个接口;T4工作负载使用了四个命名空间,每个命名空间有32个接口;最后的“混合工作负载”使用了三个命名空间,在所有的接口中:T1工作负载为16个,T2工作负载为16个,T4工作负载为32个。 逐渐增加每个接口上的通信量来衡量可扩展性,以寻找可接受性能标准范围内的最高吞吐量。为了获得可接受的性能标准,必须以持续不变的速率处理消息,无需排队,消息传递没有可测量的延迟,且平均CPU使用率必须保持在80%以下。 之前的测试表明,HL7消息类型对集成的性能或可扩展性没有显著影响;重要的影响因素包括入站消息的数量、入站和出站消息的大小、在路由引擎中创建的新消息的数量,以及修改的消息段的数量。 之前的测试还表明,在数据转换中处理HL7消息的各个字段通常对性能影响不大。这些测试中的转换通过相当简单的赋值来创建新消息。请注意,复杂的处理(例如在数据转换中使用大量的SQL查询)可能会导致结果发生变化。 之前的测试还验证了规则处理的影响通常不大。这些测试中使用的路由规则集平均为32条规则,所有规则都很简单。请注意,非常大或非常复杂的规则集可能会导致结果发生变化。 ### **硬件** #### 服务器配置 测试中使用的服务器采用了第二代Intel®可扩展Gold 6252“Cascade Lake”处理器,带有48核@ 2.1GHz的2插槽系统,每个插槽提供24个核心,并具有192GB DDR4-2933 DRAM和10Gb以太网网络接口。本测试使用的是Red Hat Enterprise Linux Server 8操作系统和InterSystems IRIS医疗版 2020.1。 #### 磁盘配置 通过IRIS 医疗版传递的消息将完全持久化保存到磁盘上。本次测试中系统内部的两个Intel 750GBIntel®Optane™SSD DC P4800X SSD驱动器分开使用,一个用于数据库,一个用于日志。此外,除了确保与真实环境进行比较之外,还对日志启用了同步提交以确保数据持久化。对于本文前面提到的T4工作负载,每条入站HL7消息都会生成大约50KB的数据,这些数据可以进行细分(如表2所述)。事务日志的在线时间通常比消息数据或日志的时间短,在计算总磁盘空间时应该考虑到这一点。<section> 表2:每条入站HL7 T4消息所需的磁盘空间</section>
组成部分 数据要求
分段数据 4.5 KB
HL7消息对象 2 KB
消息头 1.0 KB
路由规则日志 0.5 KB
事务日志 42 KB
总计 50 KB
回顾上文,T4工作负载使用路由引擎将每个修改后的消息路由到四个出站接口中的每一个接口。平均而言,每次转换都会修改入站消息的4个分段(1条入站消息对应4条出站消息,进行4次转换)。每条入站消息将进行4次数据转换,将4条消息发送到出站,并在数据库中创建5个HL7消息对象。 在配置生产系统时,计算净需求时应考虑到每日入站量、HL7消息的删除计划以及日志文件的保留策略。此外,应该在系统上配置适当的日志文件空间,以防止保存日志的磁盘卷被占满。出于性能和可靠性方面的考虑,日志文件和数据库文件应分别保存至两个物理磁盘。 ##![](/sites/default/files/inline/images/images/image-20210120152852-2.gif) **结论** InterSystems IRIS医疗版HL7v2消息吞吐量测试结果表明,简单的2插槽商用服务器配置即具有巨大的吞吐量能力,可满足任何组织中的极限消息工作负载的需求。此外,InterSystems致力于通过不断的版本迭代和升级,利用最新的服务器特性或者云技术,达到更高的性能和扩展性。 下图概述并比较了Ensemble 2015.1和Ensemble 2017.1基于英特尔®E5-2600 v3(Haswell)处理器的基准测试,以及Ensemble 2017.1基于第一代Intel®可扩展白金系列(Skylake)处理器的基准测试,和IRIS医疗版2020.1版本基于第二代Intel®可扩展黄金系列(Cascade Lake)处理器的基准测试最新结果。 图1:单个服务器上每天10小时的消息吞吐量(百万) ![](https://community.intersystems.com/sites/default/files/inline/images/images/picture-1.png) InterSystems IRIS 医疗版不断提高版本之间互操作性吞吐量的标准,并提供灵活的连接功能。如上图所示,IRIS 医疗版消息吞吐量已有显著增加,在T2工作负载情况下比2017版翻了一番,与2015版测试相比,在相同的10小时窗口内吞吐量增加了两倍多,24小时总消息速率保持在23亿以上。 证明IRIS 医疗版性能提升的另一个关键指标是更复杂的T2和T4工作负载(包含转换和路由规则,而不是T1工作负载的纯直通操作)中的吞吐量的提高。 InterSystems可随时与您探讨组织中遇到的与互操作性需求相关的解决方案。   **注:本文为译文,欢迎[点击查看原文](https://community.intersystems.com/post/intersystems-iris-health-20201-hl7-benchmark),原文由[Mark Bolinsky](https://community.intersystems.com/user/mark-bolinsky)****撰写**