简介

最近完成了针对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吞吐量基准测试相比，扩展性提高了一倍多。

大家应该都已经很熟悉 InterSystems Ensemble（一个集成和应用程序开发平台），每个人都知道 Ensemble Workflow 子系统是什么以及它对于自动化人类交互的作用。 对于那些不了解 Ensemble Workflow 的人，我将简要介绍它的功能（已经熟悉的朋友可以直接跳过这一部分并学习如何使用 Angular.js 中的 Workflow 接口）。

InterSystems Ensemble

InterSystems Ensemble 是一个集成和应用程序开发平台，旨在集成异构系统、自动化业务流程和创建新的复杂应用程序，这些应用程序通过新的业务逻辑或新的用户界面增强集成应用程序的功能：EAI、SOA、BPM、BAM 甚至 BI （感谢 InterSystems DeepSee：一种用于开发分析应用程序的内置技术）。

Ensemble 具有以下关键功能：

本文是上一篇关于如何从流行数据库（如 PostgreSQL 和 MySQL）迁移到 IRIS 的后续文章。

我们将使用与从 PostgreSQL 迁移相同的过程。 但是，您会发现它更容易，因为 MySQL 中的数据类型与 IRIS 非常相似。 这就是为什么我们不需要在列中创建转换规则。

获取示例数据到迁移过程

在 GitHub 中，可以下载 docker-compose 项目来构建和运行 2 个数据库：

• 源数据库：带有示例数据库的 MySQL 数据库 Docker 实例。
• 目标数据库：InterSystems IRIS 数据平台 Docker 实例，具有用于接收源数据库的现成模式。

要获取示例并运行它，请执行以下步骤：

(ECP) Caché 出色的可用性和扩展特性之一是企业缓存协议 (ECP)。 在应用程序开发过程中，如对使用 ECP 的分布式处理加以考虑，可以横向扩展 Caché 应用程序的架构。 应用程序处理可以调整为非常高的速率，处理能力从单个应用程序服务器扩展到最多 255 个应用程序服务器，并且不需要任何应用程序更改。

在我参与的 TrakCare 部署中，ECP 已广泛使用多年。 十年前，主要供应商之一的一台“大型”x86 服务器可能总共只有八个核心。 对于大型部署来说，ECP 是横向扩展商业服务器处理能力的方式，不适合单台昂贵的大型企业服务器。 即使是高核心数的企业服务器也有限制，因此 ECP 也用于扩展这些服务器上的部署。

如今，大多数的新 TrakCare 部署或升级到当前硬件不需要 ECP 即可扩展。 目前的双插槽 x86 生产服务器可以拥有数十个核心和巨大容量的内存。 我们看到，在最近的 Caché 版本中，TrakCare 以及许多其他 Caché 应用程序具有可预测的线性扩展能力，能够随着单台服务器中 CPU 核心数量和内存的增加而支持逐渐增多的用户和事务。 在现场，我看到大多数的新部署都是虚拟化的，即使如此，虚拟机也可以根据需要扩展到主机服务器的规模。 如果资源需求超过单个物理主机可以提供的资源，则使用 ECP 进行横向扩展。

** 2018 年 2 月 12 日修订

虽然本文是关于 InterSystems IRIS 的，但它也适用于 Caché、Ensemble 和 HealthShare 发行版。

介绍

内存以页为单位进行管理。 Linux 系统上的默认页面大小为 4KB。 Red Hat Enterprise Linux 6、SUSE Linux Enterprise Server 11 和 Oracle Linux 6 引入了一种根据系统配置提供 2MB 或 1GB 大小的增加页面大小的方法，称为 HugePages。

起初 HugePages 需要在启动时分配，如果管理或计算不当可能会导致资源浪费。因此，各种 Linux 发行版引入了默认启用 2.6.38 内核的Transparent HugePages。这是一种自动创建、管理和使用 HugePages 的方法。以前的内核版本也可能具有此功能，但可能未标记为 [always] 而是设置为 [madvise]。

Transparent Huge Pages (THP) 是一种 Linux 内存管理系统，它通过使用更大的内存页面来减少在具有大量内存的机器上进行Translation Lookaside Buffer (TLB) 查找的开销。然而，在当前的 Linux 版本中，THP 只能映射单个进程的堆栈空间。

供应商或内部团队要求说明如何为 VMware vSphere 上运行的大型生产数据库进行 CPU 容量规划。

总的来说，在调整大型生产数据库的 CPU 规模时，有几个简单的最佳做法可以遵循：

• 为每个物理 CPU 核心规划一个 vCPU。
• 考虑 NUMA 并按理想情况调整虚拟机规模，以使 CPU 和内存对于 NUMA 节点是本地的。
• 合理调整虚拟机规模。 仅在需要时才添加 vCPU。

通常，这会引出几个常见问题：

• 由于使用超线程技术，VMware 创建的虚拟机的 CPU 数量可以是物理 CPU 数量的两倍。 那不就是双倍容量吗？ 创建的虚拟机不应该有尽可能多的 CPU 吗？
• 什么是 NUMA 节点？ 我应该在意 NUMA 吗？
• 虚拟机应该合理调整规模，但我如何知道什么时候合理？

我以下面的示例回答这些问题。 但也要记住，最佳做法并不是一成不变的。 有时需要做出妥协。 例如，大型生产数据库虚拟机很可能不适合 NUMA 节点，但我们会看到，其实是没问题的。 最佳做法是指必须针对应用程序和环境进行评估和验证的准则。

Google Cloud Platform (GCP) 为基础架构即服务 (IaaS) 提供功能丰富的环境，其作为云提供完备的功能，支持所有的 InterSystems 产品，包括最新的 InterSystems IRIS 数据平台。 与任何平台或部署模型一样，必须留心以确保考虑到环境的各个方面，例如性能、可用性、操作和管理程序。 本文将详细阐述所有这些方面。

临床研究必须与健康数据相连

就在不久以前，临床科研人员还需要依靠三联的纸质NCR表格，手工收集从堆积如山的手写电子病历中提炼出来的病人数据。从又大又重的《医师案头参考》（PDR）撕下几页，通过传真机发送给FDA，用于药物安全报告。业内专业人士接受了大量的培训，以确保数据经过源文件验证、双键处理，并在经过看似无休止的查询以纠正错误之后，保证其符合目的。

值得庆幸的是，随着电子健康档案的广泛采用，健康数据的数字化，这一过程得到了极大的改善。但是，鉴于临床研究进展缓慢，特别是精美的Excel表格仍由人工数据摘要完成，该领域早该有更多的技术变革，特别是围绕释放医疗互操作性的全部好处。如果我们能做到这一点，生命科学公司将有机会利用宝贵的健康数据来确保病人的安全，优化新药的疗效，并使临床开发过程更加高效，减少错误。

索引

下文按顺序列出了数据平台上容量计划和性能系列中的所有帖子。 也列出了我的其他帖子。 我将随着该系列中新帖子的增加进行更新。

这是一个我开发的名为NiPaRobotica Pharmacy的小应用。 从附件可以看到一个界面，能够接收药房配药请求，并将订单上的行项目转换为发送给机器人的配药对话 。我在3家医院的药房部署了这个接口，其中两家药房有6个机器人被安排来将药物从分配槽配送到药剂师的窗口，每天能服务1200个病人。这些机器人能够将病人平均等待时间从2小时减少一半到1小时.接下来我把这个接口部署到专门为慢病病人建的6个配送点，例如如结核病、艾滋病毒、糖尿病、癫痫、高血压和哮喘等等。这个项目的目标是“把药物带给病人”。 这些点有六个6 ATM形式的药房配药设备 (Pharmacy Dispense Units ，PDU)，可以让病人直接与呼叫中心的药剂师沟通。在每个PDU 背后是一个存放上千种药物的大型的机器人。我的应用可以发送指令给机器人，机器人将药物分配到传送带上，送到一个打印机下面。这个打印机已经收到药房标签的内容，包括病人姓名、剂量说明和其他信息等。然后打印机把标签放下并贴在药品包装上。这包药再往前走一点就有一块海绵压住标签，使其更牢固地贴在包装上。然后，传送带将物品传送到PDU中的一个盒子里，一旦所有药物都被分发出去，病人就能打开PDU上的一个盖子，取出他的药品。这个项目最重要的意义是让病人少跑腿，不需要请假，还要长途跋涉到他们平时看病的医院，再取药回家。

医院拥有丰富的CDA文档库，如何实现数据的有效利用和共享？

本贴提供了在 VMware ESXi 5.5 及更高版本的环境中部署 Caché 2015 及更高版本时，关于配置、系统规模调整和容量规划等方面的指南。

我假定您已经了解 VMware vSphere 虚拟化平台，所以直接给出推荐。 本指南中的推荐不特定于任何具体硬件或站点特定的实现，也不应作为规划和配置 vSphere 部署的全面指南，而是一份您可以做出选择的最佳实践配置清单。 我希望您的 VMware 专家实施团队能针对具体站点对这些推荐进行评估。

这里是 InterSystems 数据平台和性能系列的其他帖子的列表。

注：本帖更新于 2017 年 1 月 3 日，强调必须为生产数据库实例设置虚拟机内存预留，以保证 Caché 有足够内存可用，并且不会出现内存交换或膨胀而对数据库性能产生负面影响。 更多详细信息，请参见下面的内存部分。

#Open Exchange

您可能已经看到邀请分享您的 Open Exchange 应用程序的演示：Share a Demo of Your Open Exchange Application

它背后的服务——InterSystems Online Demo Server (ODS)——这不是什么新事物

一. 企业信息库简介

企业信息库（MessageBank）是一个可选的远程归档设施，可以从多个来自不同实例的互操作性Production中收集信息、事件日志项目和搜索表项。如下图所示：

这套环境由两种角色的实例构成：
企业信息库服务器，它本身也是一个Production，完全由Message Bank服务组成，接收来自任何数量的客户Production提交的消息、日志等。

客户端Operation（Message Bank Operation），将其添加到一个正在运行的Production中，并用企业信息库服务器的地址进行配置。如连接通畅，消息和日志即可自动转发到Message Bank并在其中存储。

为了使你能方便地看到信息库中的信息，InterSystems IRIS®提供了以下附加选项。

对于企业信息库实例，管理门户自动包括企业监控器页面，在那里你可以监控客户端Production的状态，浏览消息库，并对被监控客户的消息进行检索。

对于每个客户端实例，你在消息库实例中配置一个到企业监控器的链接。