Host Sizing
Connexion has no minimum hardware check during installation, and does not require heavy-weight hardware to give adequate performance. We generally recommend a quad-core CPU, 4 gigabytes of memory, and 30 gigabytes of free space as adequate for simpler systems. If you require high-performance, many channels, complex channels, or will be processing large messages (MB instead of KB) then read the 'Hardware - Advanced' section below or contact Conevity for recommendations.
Most modern deployments of Connexion utilize some type of virtualized hosting, whether local or cloud. These environments often have the ability to dynamically scale resources as the Connexion and database workloads change.
Production systems typically host Connexion databases separately from the Connexion application, as this allows database-level redundancy as well as more flexible scaling. In this scenario, you will need to provision both a Connexion host and a Database host.
Recommended Sizing Approach
The most accurate way to approach sizing for production systems, if needed, is to provision a test environment with metrics enabled. This will let you simulate a production workload while monitoring resource usage, throughput, on-disk growth etc.
Hardware
It is difficult to provide specific hardware recommendations in this document, as there are many variables to consider when sizing systems. If you need help specifying hardware, please contact Conevity.
The following should be considered when sizing hardware for Connexion:
Number of Channels: Are you expecting to run 5 channels or 100? If you will be using the 'execution groups' feature of Connexion to isolate channels, an extra ~100 MB of memory will be required per group.
Channel Complexity: Are your channels performing simple operations like reading/writing HL7 and simple transformations, or are you performing heavy string manipulation or running complex database queries?
Message Composition: Are the messages you are processing 100K or 30MB? Memory requirements increase dramatically as message size increases.
Performance Expectations: What is the expected peak load? Do you have latency requirements?
Redundancy: Additional resources will be required if you are using one of SQL Server's fail-over features (mirroring, always-on, etc.)
For a typical install of up to 10 simple channels, processing a typical message stream (< 100K / message), we would recommend an absolute minimum of 2 gigabytes of memory and 2 logical cores for systems not running a local database. Systems running Connexion and database host should have a minimum of 4 gigabytes of memory and 4 physical cores.
As the channel count, channel complexity, message size, and performance requirements increase, so should your memory and processor power.
Storage
By default, Connexion stores each received message as well as relevant processing metadata for 90 days (the message retention period is user-configurable). The actual size-on-disk of each stored message will be dependent on how much processing metadata is being stored with the message (by default, a copy of the message will be stored each time it is changed by a device). A rough estimate of required free space can be calculated by multiplying the expected message size, expected message volume (for all channels) per day, and message retention period. You should multiply the result by the number of devices that change the message. For example, a channel containing a transform device will store a copy of the transformed message, and therefore be storing both the original message and the updated one.
Disk Performance
Database / Disk IO is typically the bottleneck for Connexion throughput. High-performance systems should consider investing in high throughput disk subsystems such as SSD RAID or PCI-based SSD solutions.
Memory
SQL Server will use free memory to load much of Connexion's database and reduce the number of relatively slow paging operations. The more memory, the better, although some versions of SQL Server may have hard memory usage limits.
CPU
For systems with few channels, higher clock speeds usually provide better performance. For systems with many channels, higher core counts usually provide better overall performance.