近日，SmartX 測試了超融合基礎架構對 Rhapsody 醫療整合引擎在訊息收發、處理效能上的支援效果。本次測試模擬一般三甲綜合醫院實際資料互動場景。經過對超 30 億條次的資料進行測試， Rhapsody 在 SmartX 超融合環境下單引擎訊息收發量最高達到 68 萬條訊息/分鐘，叢集訊息吞吐量穩定達到 64 萬條訊息/分鐘，相當於實際業務場景常規所需效能的 5-10 倍。這意味著 SmartX 超融合能充分支援並大幅提升醫療整合引擎效能，滿足國內絕大多數三甲綜合醫院的資訊處理需求。

背景介紹

Rhapsody 是醫療資訊互聯互通解決方案提供廠商 Lyniate（總部位於紐西蘭，中國分公司為傲醫軟體科技(上海)有限公司，以下簡稱“傲醫軟體”）旗下歷經 20 多年不斷創新的老牌整合引擎產品。Rhapsody 整合引擎為全球 60 個國家超 8300 家醫療衛生及相關機構提供安全、可靠和靈活的互操作性解決方案，是國際市場公認的頂級產品。Rhapsody 在中國已有 700 多家醫院使用者（多數為三甲醫院），助力 160 餘家國內區域單位醫院透過國家醫療健康資訊互聯互通標準化成熟度四級以上測評，並助力 50 餘家醫院透過電子病歷五級以上評價，在國內醫療行業亦受到廣泛認可。

為了進一步提高 Rhapsody 的效能，同時探索超融合在醫療行業中的應用場景，SmartX 與傲醫軟體合作測試了超融合平臺對 Rhapsody 資訊處理效能的支援效果。本次測試模擬了一般三甲綜合醫院普通掛號以及門診電子病歷書寫（包括互聯互通成熟度測評標準 CDA 文件轉換）的資料互動場景。根據設定的場景，一般三甲綜合醫院日均門診量在 5000-12000 人左右，日均互動訊息量在 300-1000 萬之間，業務高峰期訊息量最高可達 2-3 萬/分鐘。本次測試結果均以這一業務場景為參照進行對比。

我們從訊息收發、Web 服務和訊息解析三個方面測試 Rhapsody 資訊處理效能，並監測超融合環境下 Rhapsody 單機極限資訊處理能力和叢集穩定資訊處理能力。具體測試內容如下：

Rhapsody 整合引擎收發訊息極限測試
Rhapsody 整合引擎 Web 服務極限測試
Rhapsody 整合引擎 JavaScript 過濾器訊息屬性解析極限測試
Rhapsody 整合引擎叢集測試

測試環境

為了全方位測試整合引擎的效能，這次測試採用了搭載 Intel Xeon Gold 6132 CPU 的 SMTX Halo 8100 一體機，部署 3 個節點，並基於最新版本 SMTX OS 5.0.2 Boost 模式開展測試。超融合平臺具體配置情況如下：

Rhapsody 整合引擎採用典型配置的叢集部署，2 個虛擬機器伺服器（分別為主伺服器 Rhapsody master 和備用伺服器 Rhapsody slave）透過 HA-Nginx 負載均衡，master 和 slave 伺服器均配備 16 個 vCPU 和 32 GB 記憶體。具體部署情況如下：

整個測試採用極限壓力測試。根據測試的設定場景，壓力測試伺服器 P-Test 滿載壓力後訪問 HA-Nginx，HA-Nginx 根據任務和伺服器使用情況將任務分配給 master 和 slave 伺服器進行處理。測試環境的具體配置如下：

測試產品：Rhapsody V6.9.0 Windows x64
測試工具：Apache JMeter V5.4.3
負載工具：Nginx-1.20.2 Windows版

測試結果

SmartX 超融合環境下 Rhapsody 單機極限訊息收發量可到 68 萬條/分鐘。
SmartX 超融合環境下 Rhapsody 單機每分鐘可處理約 48 萬次 Web 服務請求。
SmartX 超融合環境下 Rhapsody 單機經過 JavaScript 過濾器解析訊息之後每分鐘能處理 32 萬次 Web 請求。
雖受制於網路限制，SmartX 超融合環境下 Rhapsody 叢集訊息總吞吐量依舊可以達到 64 萬條訊息/分鐘，“折算”後是實際業務場景的 5-10 倍。

測試經過和具體結果如下：

1. Rhapsody 整合引擎收發訊息極限測試

測試方法：透過高頻觸發器，向 Rhapsody 整合引擎傳送資料，Rhapsody 整合僅互動訊息，對其不做解析處理。

結果顯示， SmartX 超融合環境下 Rhapsody 平均收發量約 68 萬條訊息/分鐘。

2. Rhapsody 整合引擎 Web 服務極限測試

測試方法：透過 JMeter 工具進行測試，Rhapsody 整合引擎透過 Web Service Hosting 和 HTTP Server 通訊點（Soap Web Service 和 HTTP 介面元件）進行訊息收發。

Rhapsody 配置測試環境：透過 Rhapsody 整合引擎搭建一個 Web Service 服務，一個 HTTP 服務，每個服務各設定 30 個連線執行緒。

JMeter 測試配置環境：JMeter 新建兩個執行緒組，分別呼叫 Rhapsody 整合引擎的 Web Service 服務和 HTTP 服務，同樣每個執行緒組各 30 個執行緒。

結果顯示，SmartX 超融合環境下 JMeter TPS 約為 5000 左右， Rhapsody 整合引擎每分鐘能處理約 48 萬次 Web 服務請求。

3. Rhapsody 整合引擎 JavaScript 過濾器訊息屬性解析極限測試

測試方法：透過 JMeter 工具進行壓測，Rhapsody 整合引擎透過 Web Service Hosting 和 HTTP Server 通訊點進行訊息收發。

Rhapsody 配置測試環境：透過 Rhapsody 整合引擎搭建一個 Web Service 服務，每個服務各設定 30 個連線執行緒，Rhapsody 整合引擎透過 JavaScript 過濾器（JavaScript 功能元件）解析入參，並設定為訊息屬性，最終生成響應訊息並返回。

JMeter 測試配置環境：JMeter 新建兩個執行緒組，分別呼叫 Rhapsody 的 Web Service 服務和 HTTP 服務，同樣每個執行緒組各 30 個執行緒。

結果顯示，SmartX 超融合環境下，因為經過 JavaScript 過濾器的解析，Rhapsody 引擎整體吞吐量出現了衰減，從每分鐘約 48 萬次下降到了 32 萬次。 但 SmartX 超融合環境下 Rhapsody Web 服務依舊錶現出高效率，且整體表現穩定，無明顯波動。

4. Rhapsody 整合引擎叢集測試

測試方法：整合引擎叢集測試部署 master 和 slave 雙節點，採用單引擎 Web 服務極限測試環境進行測試。

結果顯示，SmartX 超融合環境下兩個節點都可以穩定達到 30 萬訊息/每分鐘，JMeter TPS 達到 6300。雖然受限於環境網路情況， 整個叢集訊息總吞吐量依舊可以達到 64 萬條訊息/分鐘。

由於醫院實際業務場景中採用叢集部署的模式，且考慮到現實環境可能更為錯綜複雜，對照實際業務複雜度進行“折算”（見注 1）， SmartX 超融合環境下 Rhapsody 所表現出來的效能也可達到實際業務場景的 5-10 倍，完全符合甚至超出國內一般三級甲等綜合醫院的效能需求。

Rhapsody 在測試中表現出的超高效能得益於 SMXT OS 5.0.2 版本的 Boost 模式。該模式透過 vhost 共享協議實現了 Guest OS、QEMU、分散式塊儲存 ZBS 三者之間記憶體共享，分散式塊儲存引擎器可以直接訪問到 Guest OS 的記憶體，繞開了由 QEMU 處理 I/O 請求所造成的效能瓶頸，透過縮短 I/O 路徑大幅提升效能。

總結

透過以上測試可以看出，SmartX 超融合可以良好地適配 Rhapsody 整合引擎，且單機最高資訊處理效率和叢集穩定資訊處理效率均達到一般三甲綜合醫院業務場景的 5-10 倍，表現出遠超絕大多數醫院實際環境所需的效能。同時，SmartX 超融合具備精簡的架構和良好的彈性擴充套件能力，可以大幅降低基礎設施運維難度，並實現按需投資和資源的快速交付，可以有效地支撐醫療機構實現智慧醫療的全面轉型。

注 1：

測試所使用的介面協議、資料處理、業務併發等都是實際生產通用模式，相比實際生產環境只是介面“數量”的多少和資料處理“解析-轉換”繁簡差異。

參考資料：

“Rhapsody（原 Orion Health Rhapsody）攜 Corepoint 榮膺 2020 年 KLAS 整合引擎類別冠亞軍”

點選下載。

SmartX 超融合支撐 Rhapsody 醫療整合引擎執行效率實測詳解

相關文章