Performance Improvements
Under the covers, the Connexion core messaging pipeline API has been updated to better allow for efficient processing of batches. The API remains the same as version 16, but this update allows us to make some improvements to efficiency, performance, and a better batching API for plugin developers.
Significant updates to the queue database hot path have also been made which significantly improve throughput as well as reduce on-disk size.
Updates to the way attachments and large messages are stored provide improved throughput for many operations, especially when messages are large. A new streaming API is available in v26 for attachments, which allow much more efficient read and write for large payloads.
Partitioning within the message repository database enables both faster database access and much faster database maintenance. Coupled with Tier 2 storage, databases can be kept much smaller.
All of these improvements add up to a Connexion service that is significantly faster than version 16, all while using fewer resources. A synthetic benchmark run of 1000 channels on both versions shows v26 is more than 10 times faster.
Speeds have also been improved for Remote Agent and Secure Sender communications, which now use proper end-to-end gRPC streaming (Improvements of ~3X). Branching has also been improved, especially for messages over ~10Kb.
The conversion from WPF to Avalonia, with subsequent tuning and improvements, yields significantly faster Connexion and Gateway UIs which use less memory. Both use ‘Ready-to-Run’ technology in .NET 10 to cut startup times in half.
1,000-channel performance test
In the same 1,000-channel test on Windows, the v26 screenshot shows approximately 14.3× the message processing rate of the v16 screenshot. The figures below are the live rates captured in each screenshot. [Both tests run on the same 2022 era laptop. v16 uses Sql Server, v26 was using Postgres].
Live rate | v16 | v26 | v26 / v16 |
|---|---|---|---|
Processed messages/s | 2,130 | 30,505 | 14.3× |
Queued messages/s | 2,000 | 30,351 | 15.2× |
v16: 1,000-channel test on Windows
Versions shown: 16.2.4225 / 16.2.4237.
v26: 1,000-channel test on Windows
Versions shown: 26.0.2673 / 26.0.2673.0.
Branching
In the branching test, the v26 screenshot shows approximately 4.7× the source-channel rate and 2.3× the aggregate application processing rate of the v16 screenshot.
Live rate | v16 | v26 | v26 / v16 |
|---|---|---|---|
Branch source channel (messages/s) | 250 | 1,172 | 4.7× |
Application aggregate processed messages/s | 5,360 | 12,362 | 2.3× |
These are live readings captured at different points in the runs. The application aggregate includes processing across channels, including branch destinations; it is separate from the source-channel rate.
v16: branching test on Windows
Versions shown: 16.2.4225 / 16.2.4237.
v26: branching test on Windows
Versions shown: 26.0.2673 / 26.0.2673.0.
Secure Sender
In the Secure Sender test, the v26 screenshot shows approximately 8.9× the source-channel rate of the v16 screenshot: 2,129 versus 239 messages/s.
Live rate | v16 | v26 |
|---|---|---|
Source channel (messages/s) | 239 | 2,129 |
These are live readings captured at different points in the runs. Receiving messages into the target queue and processing them through the target channel are separate stages. The target-channel rates and application aggregates are shown separately from the source-channel transfer rate.
v16: Secure Sender test on Windows
Versions shown: 16.2.4225 / 16.2.4237.
v26: Secure Sender test on Windows
Versions shown: 26.0.2673 / 26.0.2673.0.
Remote Agent
Connexion to Remote Agent
The captured source-channel transfer rate increased from 329 messages/s in v16 to 3,240 messages/s in v26—approximately 9.8× the v16 rate. The improvement is similar in the other direction (Remote Agent to Connexion).
Live transfer rate | v16 | v26 | v26 / v16 |
|---|---|---|---|
Source channel (messages/s) | 329 | 3,240 | 9.8× |
v16: 329 messages/s — source-channel transfer rate captured during the test.
v26: 3,240 messages/s — source-channel transfer rate captured during the test.
Parallel processing within a device
Devices that do independent work on each message (the HL7v2 to FHIR, HL7v2 to C-CDA, FHIR Validator and C-CDA Validator devices, for example) can process the messages of a batch on several threads. The setting is in the device header: 1, 2, 4, 8, 12 or 16 threads, with 2 as the default. Messages within a batch can finish in any order, but the batch keeps its order when it is passed to the next device.
Conversion and validation are CPU work, so a single thread was these devices' limit. Throughput rises nearly in proportion to the thread count up to four threads, and keeps rising more slowly after that.
Device (messages/s) | 1 thread | 2 | 4 | 8 | 8 threads vs 1 |
|---|---|---|---|---|---|
C-CDA Validator | 160 | 310 | 600 | 885 | 5.5× |
FHIR Validator (cached terminology) | 226 | 339 | 953 | 1,151 | 5.1× |
HL7v2 to FHIR (typical ADT) | 690 | 1,540 | – | – | 2.2× at 2 threads |
These rates are each device's own processing rate, not a whole channel's, measured on an Intel Core i9-12900HX laptop (8 performance and 8 efficiency cores). A higher setting helps only while cores are free; on a busy server, other channels compete for the same cores.
Plugin developers can opt their own devices in; see Plugin Developers: What You Need to Know for v26.