The scenario
A file of approx. 11 MB of data contains 2350 messages (administrative patient data, SAP-HCM, fixed format) to be processed. For each route to a destination system there are 7 Message IDs that lead into 7 different Message Translations (Ids and Translations are taken from our production environment). Each of the messages are to be translated into HL7, version 2.2. Each destination system (Communication Client = e*Way) produces a file containing 2050 messages (not all of the incoming messages are labeled) of about 1.2 MB size. Tests with 1 destination system and with 5 destination systems are carried out.
Tests are run on a Sun Sparc Ultra Enterprise 2 with 2 CPUs (200 MHz) and 512 MB RAM. The operating system used is Solaris 2.6.
8 different configurations are tested, 3 running e*Gate 3.6.2 and 5 running 4.1.1.
Configuration A (e*Gate 3.6.2): A Comm Client reads the HCM-data from a single input file. The e*Gate Server routes the messages to one destination using 7 different Message IDs and 7 Translations. The destination is an outbound Com Client that writes the messages to a second (outbound) file. The Message IDs are optimized; they parse only the message header not the whole message.
Configuration B (e*Gate 3.6.2): A single Com Client reads in the data from the input file. Instead of a single outbound comm client there are 5 destination clients all writing to their own outbound files. Each client has it's own copy of the 7 IDs and 7 translations. The IDs are exact copies (no unique names for each of the destination systems), giving the Server the chance to optimize. In other words, for one incoming message only 7 ID-operations have to be performed, not the configured 35. For each message that is labeled 5 Translations need to be performed by the Server.
Configuration C (e*Gate 3.6.2): One inbound client feeds 5 destination (outbound) clients. The only difference between this configuration and configuration B is that all of the message IDs have unique names. Consequently, the server has to check all of the 35 message IDs.
Configuration D (e*Gate 4.1.1): An e*Way reads in the data from the input file. It runs a pass-through Collaboration placing all incoming messages in an IQ (STC_Standard IQ-Service) using only one generic Event Type. A collaboration running on the destination e*Way subscribes to this Event Type. This Collaboration does all the work. A large if-then-else statement is employed to handle the Message IDing, translating and publishing (similar to the example given in the Working with e*Gate 4.0 Collaboration-IDs document). IDing is done directly via regex functions rather than calling external functions. The translations, however, are configured to use external function calls. This implementation is more optimized than the IDing in configuration A, B, and C. Message parsing has to be performed only once. The result of the translation is written to an output file.
Tests were performed using the old communication clients (wrapped with Proxy-e*Ways) and with stcewfile-e*Ways.
Configuration E (e*Gate 4.1.1): This configuration is similar to Configuration D, except that 5 destination e*Ways have been configured to work in parallel. All e*Ways subscribe to the same Event Type in the IQ. Messages are written to 5 separate output files.
Configuration F (e*Gate 4.1.1): This configuration is similar to Configuration D. An additional BOB is inserted between the incoming and the destination e*Way. The incoming e*Way publishes the messages to one IQ; the BOB subscribes to them and executes the Collaboration that formerly ran on the destination e*Way. The BOB publishes the results to a second IQ to which the destination e*Way subscribes. It’s only configured with a pass-through-Collaboration.
Configuration G (e*Gate 4.1.1): This configuration is similar to Configuration F with 5 subscribing destination e*Ways. Unlike Configuration E the translation is only performed once. The e*Ways all subscribe to the same Event Type in the second IQ. The configuration is highly optimized, more than even configuration B, and is similar to an e*Gate 3.6.2 translation using message-send to feed more than one destination.
Configuration H (e*Gate 4.1.1): In this configuration the BOB runs 5 different Collaborations in parallel which all subscribe to the same Event Type in the first IQ. When publishing the results to the second IQ, they all use a different Event Type. Each outgoing e*Way subscribes only one of the 5 Event Types in the IQ. This is similar to the old server in configuration C.
The results
e*Gate 3.6.2 performs as expected. Configuration A needs aprox. 2:45 min for the complete run. Configuration B runs twice as long, approx. 5:30 min due to the additional translations and the extra work required for routing. Configuration C runs 4.5 times longer than configuration A (about 13 min). When compared to B for each message 28 additional IDs have to be checked. In all of the runs the Server process used 45-48% of the available CPU using only one of the two CPUs.
Configuration D (using e*Gate 4.1.1) runs a bit faster than Configuration A (using 3.6.2) due to the fact that it takes advantage of the simplified IDing. The configuration is slowed down by the IQ-Manager which runs as an additional process (the IQ-Manager uses 2% of the CPU-time available).
It was observed that the throughput of configuration D worsened when several successive runs of the same test were performed. The first run needed 2:40 min, the fourth run 3:20 min (as shown by the different dots in the graph). It can be shown that this effect was caused by the growing IQ-files that had to be managed by the IQ-Manager. Additional observations revealed that the IQ-Manager grew (12 MB in the first run, 33 MB in the fourth) taking more and more CPU time. Deleting the IQ-files in between the runs solved this problem.
No significant differences were observed between configurations using the stcewfile-e*Ways and the runs using Proxies.
The results of configuration E reveal that e*Gate 4.1.1 scales nicely. The processes utilize both CPUs to nearly 100%. The configuration processes the messages in about 7:10 min, only 55% of the time required by Configuration C. With additional CPUs even better results could have been achieved.
Configurations F to H were designed to show the impact of an additional BOB. The results were ambivalent. Configuration F needed 3:20 min which is a bit slower than A and D. Configuration G also demonstrated that e*Gate 4.1.1 scales nicely. The task performed by this configuration, one message sent to 5 different destinations, was solved quite elegantly.
Configuration H performed badly. It required approximately 12 min to process all of the messages (not any faster than configuration C), even with the BOB using 85% of the available CPU cycles and the IQ-Manager another 12%. This leads to the conclusion that the topology used is worse than the one used in configuration E. Five times more write-operations to the IQ are needed as well as five times more messages to administer for the IQ-Manager (it makes no difference if the messages are written to one or 5 IQs).
A closer look at the output files and the timestamps revealed that the
internal threading of the BOBs doesn't work properly. Not all of the 5
Collaborations process the messages at the same speed (3.6.2 has similar
problems). Configuration E doesn't show this effect.
Conclusions