Using OnixS::CME::iLink3::SessionStorageType::MemoryBased instead of OnixS::CME::iLink3::SessionStorageType::FileBased boosts performance, since SBE messages are stored directly in memory.
Alternatively, it's possible to use pluggable storage ( OnixS::CME::iLink3::SessionStorageType::Pluggable ) that does nothing on message-related operations.
Also, you can use the Asynchronous File-Based Session Storage if you need to keep the file-based storage functionality and excellent performance.
By default, session threads can be executed on any of the available processors/cores. Specifying CPU affinity for each thread may give a significant performance boost:
To modify threads prioritis, use the OnixS::CME::iLink3::Threading::ThisThread::priority, OnixS::CME::iLink3::Session::receivingThreadPriority, and OnixS::CME::iLink3::Session::sendingThreadPriority methods.
To modify threads scheduling policies, use the OnixS::CME::iLink3::Threading::ThisThread::policy, OnixS::CME::iLink3::Session::receivingThreadPolicy, and OnixS::CME::iLink3::Session::sendingThreadPolicy methods.
SCHED_RRscheduling policies implement the fixed-priority real-time scheduling, so threads with these policies preempt every other thread, which can go into starvation.
EF_POLL_USECenvironment variable or the
When a session receiving thread attempts to read from a network and no incoming messages are available, the thread will enter the OS kernel and block (so-called "blocking wait" mode). When an incoming message becomes available, the network adapter will interrupt the CPU, allowing the OS kernel to reschedule the thread to continue.
Blocking, interrupts, and thread context switches are relatively expensive operations and can negatively affect the latency.
The session can be configured to spin on the processor in user mode for up to a specified number of microseconds waiting for messages from the network using the OnixS::CME::iLink3::Session::receiveSpinningTimeout method. If the spin period expires, the session will revert to normal blocking behavior.
OnixS::CME::iLink3::Session::receiveSpinningTimeout usage makes sense when the session receives SBE messages frequently, in this case, waiting in the loop is cheaper than the thread context switch to the "blocking wait" mode.
The OnixS::CME::iLink3::Session::sendSpinningTimeout method can be used to decrease the latency of the message sending.
If the value is zero (by default) and the outgoing message cannot be sent immediately, it is saved to the outgoing queue. If the value greater than zero, the OnixS::CME::iLink3::Session::send method waits for the socket sending buffer availability in the spin loop mode before placing the message to the outgoing queue (to be sent later by the sending thread).
OnixS::CME::iLink3::Session::sendSpinningTimeout usage makes sense when the session sends SBE messages frequently, in this case, waiting in the loop is cheaper than the thread context switch.
If the session sends SBE messages infrequently, the sending path and associated data structures will not be in a cache, and this can increase the message sending latency.
One can periodically (a recommended interval is
500 microseconds or less) call the OnixS::CME::iLink3::Session::warmUp to avoid cache misses and keep the sending path fast.
By default, the logging of an outgoing message to the session storage is performed before sending it to the wire. This approach is more reliable because the outgoing message is stored before going to the counterparty. However, this approach adds the logging latency to the message sending latency, so it increases the tick-to-trade latency.
When the latency is more important, one can switch off the logging before sending, by setting the OnixS::CME::iLink3::Session::logBeforeSending option to
false. In this case, the logging of outgoing messages to the session storage will be performed after sending them to the wire.
A common strategy is to use the same outgoing application-level message instance multiple times.