Inter-Process Communication with CoralQueue

CoralQueue is great for inter-thread communication, when both threads are running in the same JVM. However it also supports inter-process communication (IPC) through a shared memory mapped file so that two threads running on the same machine but on different JVMs can exchange messages. This is much faster than the other option which would be network access through loopback. In this article we will examine how this can be easily done and present the benchmark numbers for IPC. Continue reading

Inter-thread communication within CoralReactor

CoralReactor was built on purpose, from the ground up, to be single-threaded. That means that no other thread besides the reactor thread should be executing any code or accessing any data belonging to servers and clients. This not only provides super-fast performance but also allows for much simpler code that does not have to worry about thread synchronization, lock contention, race-conditions, deadlocks, thread starvation and many other pitfalls of multithreaded programming. However there are common scenarios where other threads must interact with the reactor thread. In this article we analyze in detail how this is done, without breaking the single-threaded design principle and without creating any garbage. Continue reading

Architecture Case Study #1: CoralReactor + CoralQueue

You need a high throughput application capable of handling thousands of client connections simultaneously but some client requests might take long to process for whatever reason. How can that be done in an efficient way without impacting other connected clients and without leaving the application unresponsive for new client connections? Continue reading

CoralStore Performance Numbers

CoralStore can write a 256-byte message to disk in around 159 nanoseconds through the FileStore implementation. Moreover, by using the AsyncStore you can get even lower latencies (60 nanoseconds) and variance, as the numbers on this article demonstrate. Continue reading

Ultra low-latency with CoralFIX and CoralReactor

Please note that this benchmark sends real ExecutionReport FIX messages. It simulates the very real trading scenario where your order is filled and your strategy needs to react as soon as possible. Furthermore, our clients run our benchmarks in their own environment. We provide all the source code of our benchmarks so clients can modify and adapt them in order to reach their own conclusions. They also run their own and very specific benchmarks and tests with similar results. This benchmark not only measures the FIX parser performance, but also and most importantly the network I/O performance. If you want to check our tick-to-trade latencies you can click here.

To test the performance of CoralFIX + CoralReactor we have developed a simple test with a fix server and a fix client. The client connects to the server, the standard FIX handshake through LOGON messages happens and the server proceeds to send 2 million FIX messages to the client. So we are measuring one-way latency from FIX server to FIX client over loopback. For a throughput benchmark instead you can check this article. Note that the server only sends the next message to the client when it gets a message back from it so we can correctly measure the time it takes for each message in isolation to travel from the server to the client. We then compute the average latency, which includes the full CoralFIX parsing time (i.e. encoding and decoding of the FIX message) plus the full CoralReactor TCP network I/O time. Below we present the latency results and the source code. Continue reading

Blazing Fast Throughput with CoralFIX + CoralReactor

To test the performance of CoralFIX + CoralReactor we have developed a simple test with a fix server and a fix client. The client connects to the server, the standard FIX handshake through LOGON messages takes place and the client proceeds to send (i.e. push) 5 million FIX messages to the server as fast as it can. Then the server receives and processes all the messages calculating the throughput. So we are are measuring the one-way throughput over loopback. For a latency benchmark instead you can check this article. Below we present the throughput results and the source code. Continue reading

The Pinned Thread Difference

To illustrate the advantage of a pinned thread, we code a program that launches a bunch of threads to do a simple task and pin one of them to a processor. At the end you can see that the pinned thread is much ahead of the other threads. That’s because the other threads have to compete for the available processors while the pinned thread has a whole processor for itself. Without context switches and interruptions the pinned thread can perform its job much faster than the other ones. Continue reading