|Table of Contents|
There are two main patterns which can be used when processing incoming messages in FIX Antenna HFT:
The first one is used when message processing or routing does not take significant amount of time. In this case messages could be routed directly from the process() callback method. This assures the lowest latency possible.
If the number of incoming sessions is big, it is advised to set TCPDispatcher.NumberOfWorkers = 3, which means 3 dedicated threads for running epoll_wait calls. Also, it is recommended to either set TCPDispatcher.IncomingConnectionOnloadStackAffinity = false or specify several listen ports - this will assure even load distribution from all acceptors.
The second one (called a thread pool) is used when message processing or routing takes significant amount of time. In this scenario, the client code should create a thread pool (using Utils::ThreadsPool class ) inside the application and pass the messages pointer to the internal queue in the process() callback method in order the thread pool to start processing messages.
The above considerations are illustrated on the diagram below:
Actually, there are many sessions in the 'With user thread pool' diagram, each of them works as the shown one.
The test scenario is the following:
- Round-trip time (RTT);
- Socket to the process() callback latency on the simple router;
- The put() callback to socket latency on the simple router.
The test configuration schema (70 Sender (Initiator) sessions - 20 Receiver (Acceptor) sessions) is the following:
The histograms below show the distribution of the RTT/2 for 1,000; 5,000 and 10,000 msg/s message rates for configuration with 70 senders and 20 receivers without thread pool and with thread pool.
The following histogram compares the distribution of RTT/2 for 10,000 msg/s message rate for configuration with 70 senders and 20 receivers without thread pool and with thread pool.