Recently, collaborating with Lyniate, SmartX tested the messaging capability of Rhapsody, a healthcare integration engine, on the hyperconverged infrastructure (HCI). After processing more than 3 billion messages, we got impressive results that with hyperconverged architecture, Rhapsody’s ultimate performance in exchanging messages soared to 680,000/min under sole-engine condition and 640,000/min under cluster condition. 

This means that Rhapsody’s messaging capability boosted by HCI could totally meet the requirement of most Chinese Grade 3A comprehensive hospitals, with the messaging efficiency 5-10 times of that in the production environment. Put another way, this test is concrete proof of SmartX HCI’s strong support for the healthcare integration engine, especially in message exchange and processing.

Background

Rhapsody is a worldwide renowned product of Lyniate which is a New Zealand healthcare interoperability solution provider. It provides secure and reliable support for more than 8,300 healthcare institutions and related organizations across 60 countries. 

To further improve Rhapsody’s performance and explore the application scenarios of hyperconvergence in the healthcare industry, SmartX cooperated with Lyniate Rhapsody and examined Rhapsody’s messaging capability in the hyperconverged environment. In this test, we simulated a common Chinese Grade 3A comprehensive hospital’s data exchange procedure and amount throughout the registration and ambulatory EHR reading and writing. In China, generally, a common Grade 3A comprehensive hospital would serve 5,000-12,000 outpatients per day, generating 3 million to 10 million messages per day and maximally 20,000-30,000 messages per minute. All test results were compared with these numbers.

We measured Rhapsody’s messaging capabilities from three aspects: 1) receiving and sending (without processing) messages, 2) addressing Web Service requests, and 3) processing messages. We also respectively tested Rhapsody’s ultimate performance under sole-engine condition and cluster condition. Bellow were the four major tasks of the test:

  1. Examine Rhapsody’s ultimate performance in receiving and sending messages under sole-engine condition;
  2. Examine Rhapsody’s ultimate performance in addressing Web Service requests under sole-engine condition;
  3. Examine Rhapsody’s ultimate performance in processing messages through JavaScript filter under sole-engine condition;
  4. Examine Rhapsody’s stable messaging capability under cluster condition.

Testing Environment

To comprehensively examine Rhapsody’s performance, we deployed 3 SMTX Halo 8100 appliances supported by Intel Xeon Gold 6132 Processor and SMTX OS 5.0.2 (SmartX’s HCI software with the Boost Mode to reduce I/O latency). The hardware configuration of HCI platform was as follows:

Rhapsody was deployed in a two-VM-servers cluster (with Rhapsody master server and Rhapsody slave server) which is the typical deployment in the production environment. Both the master and slave servers were configured with 16 vCPUs and 32 GB memory. 

We conducted a stress testing to examine Rhapsody’s ultimate messaging performance. The test started with a P-Test server simulating the highest workload according to the settings and accessing HA-Nginx server. HA-Nginx server then distributed workload to master and slave servers for processing. The configuration of Rhapsody and testing environment were as follows:

Result

In short, with SmartX HCI, Rhapsody could

  • exchange up to 680,000 messages per minute;
  • address up to 480,000 Web Service requests per minute;
  • process up to 320,000 Web Service requests per minute;
  • exchange up to 640,000 messages per minute under cluster condition, despite the network limitation. Counting in the complexity of the real production environment, HCI-supported Rhapsody is 5-10 times more efficient than that required in the production environment.

Detailed results were as follows:

1. Rhapsody’s ultimate performance in receiving and sending messages

Method: We sent messages to Rhapsody through a high frequency trigger. Rhapsody only exchanged messages instead of processing them.

Results showed that on average, Rhapsody could exchange up to 680,000 messages per minute.

2. Rhapsody’s ultimate performance in addressing Web Service requests

Method: We did the test with JMeter. Rhapsody accepted and sent messages through Web Service Hosting and HTTP Server (Soap Web Service and HTTP Interface & Component). 

Rhapsody testing environment configuration: Rhapsody was integrated with Web Service and HTTP service, each with 30 connection threads.

JMeter configuration: We created two thread groups in JMeter, which respectively called Web Service and HTTP service of Rhapsody and had 30 connection threads each.

Results showed that as JMeter TPS reached around 5,000, Rhapsody could address up to 480,000 Web Service requests per minute.

3. Rhapsody’s ultimate performance in processing messages through JavaScript filter

Method: We did the test with JMeter. Rhapsody accepted and sent messages through Web Service Hosting and HTTP Server (Soap Web Service and HTTP Interface & Component). 

Rhapsody testing environment configuration: Rhapsody was integrated with Web Service and HTTP service, each with 30 connection threads. Rhapsody parsed input parameters through JavaScript filter with the attribute set as messaging and generated and returned response messages.

JMeter configuration: We created two thread groups in JMeter, which respectively called Web Service and HTTP service of Rhapsody and had 30 connection threads each.

Results showed that after processing messages through JavaScript filter, Rhapsody’s messaging efficiency reduced from 480,000/min to 320,000/min, yet still surpasses hospitals’ requirements. Rhapsody’s overall performance was also stable throughout the test.

4. Rhapsody’s stable messaging efficiency under cluster condition

Method: The cluster consisted of Rhapsody master and Rhapsody slave servers. The testing environment was configured the same as that in the sole-engine Web Service test.

Results showed that with SmartX HCI, both two nodes could stably exchange 300,000 messages per minute with JMeter TPS reaching 6300. The whole cluster’s messaging capability even reached 640,000/min despite the network limitation. As the real production environment can be more complex than the testing environment, we counted in the efficiency loss and confirmed that HCI-supported Rhapsody was 5-10 times more efficient than that required in the production environment of common Grade 3A comprehensive hospitals in China.

Rhapsody’s superior performance in the testing environment can be attributed to the Boost Mode in SMXT OS 5.0.2. This feature achieves memory sharing among Guest OS, QEMU, and ZBS, SmartX’s distributed block storage software, through the Vhost protocol. Chunk can directly access the memory of Guest OS, bypassing the performance bottleneck caused by QEMU processing I/O requests, thus greatly improving the ability of I/O processing.

Conclusion

This test demonstrates SmartX HCI’s outstanding capability in supporting Rhapsody. Overall, the result showed that under both the sole-engine and cluster condition, the ultimate performance of HCI-supported Rhapsody was 5-10 times more efficient than that in the production environment of common Grade 3A comprehensive hospitals, much surpassing the messaging capability required by most Chinese hospitals. 

Featuring streamlined architecture and flexible scalability, SmartX HCI effectively reduces the difficulty of IT operations and maintenance and enables on-demand investment and fast deployment, providing full support to healthcare institutions’ digital transformation.  

Continue Reading