The FIX Engine and FIX sessions allocate memory for internal structures during the work. The amount of allocated memory can affect the overall performance. The following articles describe how to optimize the amount of allocated memory.

Using OnixS::FIX::Session::scheduleShrinkToFit() Method

Receiving Part

When a large message with many repeating groups is received, for example, SecurityList (y), the session allocates the memory for this message and each repeating group instance. This can increase memory consumption, especially when there are many such sessions. For performance reasons, this memory is not deallocated during the FIX connection lifetime because the deallocation and further allocation of new memory are expensive, so it cannot be performed after receiving each message. This memory is deallocated only after the OnixS::FIX::Session::logout call. However, in some cases, it makes sense to have the ability to shrink this memory after receiving large messages. In such cases, the OnixS::FIX::Session::scheduleShrinkToFit method can be used. This method will schedule the memory usage optimization of the receiving part. The session will perform the actual memory usage optimization after receiving and processing the next session-level incoming message.

Sending Part

When a session sends messages at a high rate or the counterparty cannot process them fast enough, the system socket is overflowed and cannot accept new data, and the OnixS::FIX::Session:send method stores outgoing messages in the sending queue for the following process in the sending thread. Transferring an outgoing message to the sending queue is done via the message pool. The message pool memory is not deallocated after each message processing for performance reasons. The pool returns memory in time following a heuristic algorithm when the message rate decreases. However, in different scenarios, when there is a long period between high-rate sending, the memory can leave occupied until the next sending activity period. Therefore, it makes sense to have the ability to shrink the pool memory after an overflow issue. In such cases, the same OnixS::FIX::Session::scheduleShrinkToFit method can be used. This method will schedule the memory usage optimization of the sending part. The session will perform the actual memory usage optimization before sending the next outgoing session-level message.

Note: The OnixS::FIX::Session::scheduleShrinkToFit method should be used when an overflow issue is gone. One can detect it by the OnixS::FIX::Session::outboundQueueBytes method. Please see the Controlling Outgoing Message Flow topic for details.

Optimizing FIX Dictionaries

When a FIX Message is constructed, a space for all the fields, defined for the message, is allocated. The latest FIX specifications define a lot of fields for each message type. Even when most of the fields are not used, FIX Engine reserves space for them, and this has a negative effect on FIX Engine's performance. Editing Dictionaries Descriptions and excluding messages and fields (especially repeating groups) which are not used by an application, have a direct influence onto the amount of allocated memory.

Using Optimal Values of OnixS::FIX::Session::resendingQueueSize() Setting.

The OnixS::FIX::Session::resendingQueueSize setting specifies how many messages can be resent if a counterparty requests them. The session stores information about sent messages in the corresponding container. For performance reasons, this container allocates all necessary memory in advance when the session is constructed following the OnixS::FIX::Session::resendingQueueSize setting. Therefore, setting the OnixS::FIX::Session::resendingQueueSize to a large value can lead to unnecessary memory consumption. We recommend setting it to some limit value consistent with your system memory availability and resending requirements. If the resend requests functionality is not required, it is better to set it to zero.