Performance
Synthetic benchmark observations and factors that influence real deployments.
FireSonic was tested with synthetic HL7 interoperability workloads focused on common healthcare integration scenarios. The benchmark environments intentionally represented lightweight deployment configurations rather than dedicated high-performance infrastructure.
The results below are synthetic benchmark observations and operational measurements, not guaranteed production throughput. Real performance depends on the downstream FHIR server, network latency, message complexity, scripts, terminology calls, storage, JVM configuration, and deployment topology.
Local synthetic benchmark environment
| Component | Specification |
|---|---|
| CPU | Intel Core i7-8750H (6 cores) |
| Memory | 16 GB RAM |
| Storage | Samsung SSD |
| Operating System | Windows x64 |
| Runtime | Java 25 |
The workstation simultaneously ran FireSonic, the HL7 benchmark client, mock FHIR sink, Grafana, Prometheus, Docker, Firefox, and additional desktop applications. Approximately 5 GB of system memory remained available during the benchmark.
Local synthetic benchmark results
The benchmark used synthetic ADT^A01 messages and a mock FHIR sink that accepted transaction Bundle POST requests, returned successful responses, and collected delivery metrics.
| Metric | Observation |
|---|---|
| Message type | ADT^A01 |
| Average HL7 payload | 2–3 KB |
| Total messages tested | 50,000 |
| Peak HL7 intake rate | 1800+ msg/sec |
| Peak Bundle delivery rate | 200+ POST/sec |
| Persistence | Enabled |
| Monitoring | Enabled |
The local test focused on intake throughput, asynchronous queue processing, local persistence, FHIR Bundle generation, and delivery pipeline behavior rather than the limitations of a production FHIR server.
Cloud deployment stability test
| Component | Specification |
|---|---|
| Cloud provider | AWS EC2 |
| Instance type | t3.small |
| CPU | 2 vCPU |
| Memory | 2 GB RAM |
| Operating System | Ubuntu 26.04 LTS |
| Java runtime | Java 25 |
| Deployment model | Docker-based |
FireSonic, Grafana, Prometheus, the mock FHIR sink, and Docker ran on the same instance. Repeated stability testing processed approximately 500,000 HL7 messages per day, or about 3.5 million messages per week.
The environment remained operational during repeated high-volume tests. CPU and memory utilization increased during intensive processing and returned toward baseline after the load completed. Temporary slowdown can occur on burstable instance families such as t3.small when CPU-credit behavior becomes relevant.
Cloud batch throughput observation
| Metric | Observation |
|---|---|
| Source | Local workstation over Internet |
| Message type | ORU^R01 |
| Average HL7 payload | ~5 KB |
| Batch size | 10,000 messages |
| End-to-end batch time | ~143 seconds |
| Observed end-to-end rate | ~70 messages/sec |
The 10,000-message batch measurement covers intake, transformation, and FHIR delivery for the complete batch. The sender and AWS deployment were separated by real Internet latency.
What affects production throughput
- Downstream FHIR server performance.
- Network latency and transport quality.
- FHIR Bundle size and resource complexity.
- Customer Groovy workflow execution.
- Terminology and external service calls.
- Storage latency and write endurance.
- JVM configuration and available CPU/memory.
- Deployment topology and concurrent integration workloads.
Benchmark the complete deployment—including the real downstream FHIR server and organization-specific scripts—before defining production capacity or rate limits.