What is Chronicle Queue Enterprise?
A Low-Latency Message Queue
Chronicle Queue Enterprise is a "record everything" message queue designed to operate with microsecond real-time latency. It enables rapid interprocess communication (IPC) without impacting system performance, making it ideal for transferring and storing large volumes of data in low-latency environments—such as the most demanding High Frequency Trading systems, where comprehensive data recording is essential.
Chronicle Queue Enterprise functions similarly to a broker-less, durable, and persisted JVM topic, offering distributed and unbounded message storage. Key capabilities include:
Asynchronous RMI and Publish/Subscribe interfaces with microsecond latency.
Message transfer between JVMs in under one microsecond (in optimized scenarios).
Message transfer between JVMs on different machines via replication in under 10 microseconds (in optimized scenarios).
Stable, soft real-time latencies supporting millions of messages per second for a single thread to one queue, with total event ordering.
Efficiency
Chronicle Queue Enterprise is engineered to achieve latencies under 40 microseconds for 99% to 99.99% of operations. Without replication, it consistently delivers end-to-end latencies below 40 microseconds across multiple services. Actual latency performance for the 99th percentile is largely influenced by the operating system and hard disk subsystem used.
Benchmarks
When publishing 40-byte messages, a high percentage of the Chronicle Queue Enterprise yields latencies under 1 microsecond. In the tables below, the 99th percentile latency is the worst 1 in 100, and the 99.9th percentile is the worst 1 in 1000 latency.
Table 1. Latency to send/receive on the same machine. |
Batch Size | 10 million events per minute | 60 million events per minute | 100 million events per minute |
|---|---|---|---|
99%ile | 0.78 µs | 0.78 µs | 1.2 µs |
99.9%ile | 1.2 µs | 1.3 µs | 1.5 µs |
Table 2. Latency to send/receive on a second machine |
Batch Size | 10 million events per minute | 60 million events per minute | 100 million events per minute |
|---|---|---|---|
99%ile | 20 µs | 28 µs | 176 µs |
99.9%ile | 901 µs | 705 µs | 5,370 µs |
No Garbage Collection
High-performance applications cannot tolerate the unpredictable slowdowns caused by Java’s garbage collector when cleaning the heap. Chronicle Queue Enterprise eliminates garbage collection pauses by manually managing memory with RandomAccessFiles. As a result, Chronicle Queue acts as a management interface for off-heap memory, enabling users to build custom solutions for exceptionally fast interprocess communication (IPC) without impacting system performance.
Persistent
Chronicle Queue Enterprise is designed with the assumption that disk space is inexpensive compared to memory. It fully utilizes available disk space and is not limited by the machine’s main memory. A standard spinning HDD can store many terabytes of data at low cost. All data is saved in memory-mapped files, resulting in minimal on-heap overhead—even with up to 100 TB of data.
Unlike broker-based systems, Chronicle Queue Enterprise relies on the operating system (OS) for data management. If an application fails, the OS continues running for several seconds longer, ensuring no data is lost—even without replication.
Compression
Chronicle Queue Enterprise replication supports Chronicle Wire Enterprise, enabling real-time compression by calculating object deltas as they are written. This can reduce message sizes by a factor of 10 or more, without batching or introducing significant latency.
Chronicle Queue Enterprise also supports LZW, Snappy, and GZIP compression. These formats may add significant latency and are best suited for scenarios with strict network bandwidth limitations.
Delivery Mode Semantics
Chronicle Queue Enterprise offers flexible delivery semantics:
Replay every message on restart.
Play only new messages after restart.
Restart from any known point using the entry index.
Replay only missed messages, supported directly via methodReader/methodWriter builders.