Implementing EventQueueGroups

Vikram_kumar26

We are using RFA C++ 8.2.4.E1. To increase the throughput of our application we are looking for ways to improve its performance.
At present we run the single-threaded client model (Section-17.4.2) with one event queue. Because only one thread processes the incoming event data, the maximum rate we can achieve is about 6,500 updates/second.
To raise this figure we have explored the options described in the RFA documentation and found the EventQueueGroup concept (Section-10.1.2), which allows several event queues to be created and added to a single group.
The documentation, however, does not explain how an application should consume the events that are placed in those queues.Could you please confirm the following points?

1. After an EventQueueGroup is created, does RFA automatically distribute incoming events among the queues, or must the application perform the distribution itself?
2. What code changes are required to support multiple queues? Do we need a separate consumer thread for each queue?
3. How does queue->dispatch() and processEvent() work in this scenario? Must we invoke the dispatch call on every queue we created, or does RFA handle it for us?
4. Could you advise how much performance improvement we might expect if we implement this approach?

Jirapongse

@Vikram_kumar26

Thank you for reaching out to us.

After an EventQueueGroup is created, does RFA automatically distribute incoming events among the queues, or must the application perform the distribution itself?

An event queue group is a container that holds multiple event queues and behaves like a single logical queue. Applications typically use an event queue group to prioritize event dispatching across different event queues.

Even when using an event queue group, the application must still specify which individual event queue to use when registering a client. For example:

pHandle = _pOMMConsumer->registerClient(
    _pEventQueue,

    &ommItemIntSpec,

    *this,

    (void*)&itemName

);

The application must also provide a thread to dispatch events from the event queue group. The group will then prioritize events based on the priority levels of the queues it contains. As a result, using an event queue group does not increase the overall number of processed events, since all events are still dispatched by a single application thread.

In summary, an event queue group is useful for prioritizing items. High‑priority items can be registered to high‑priority event queues, while lower‑priority items can be assigned to queues with lower priority.

For more information, please refer to the 10.1.2 Using Event Queue Groups section in the RFA Developer Guide.

What code changes are required to support multiple queues? Do we need a separate consumer thread for each queue?

To improve the performance, you can use the multiple event queues and distribute subscribes items among those event queues. Then, each queue will be dispatched by a dedicated application thread. For more information, please refer to the 17.4.5 Multiple Event Queues (Client Model) section in the RFA Developer Guide.

How does queue->dispatch() and processEvent() work in this scenario? Must we invoke the dispatch call on every queue we created, or does RFA handle it for us?

An application must have a dedicated thread to dispatch each queue to process events concurrently.

Could you advise how much performance improvement we might expect if we implement this approach?

Sorry, we don’t have an exact number. However, overall performance will be better than using a single dispatching thread because multiple threads are used to dispatch and decode events.