Liberator's throttling feature allows you to reduce the performance impact of high update rates by merging updates together.

In a fast moving market, data updates can be generated more frequently than the end-user can actually notice them. For example, the user can't actually see every update for an item that is updating at ten times a second. Additionally, having to feed such high update rates through to client applications can adversely impact system resources, performance, and the network.

When throttling is enabled, Liberator accumulates all the updates for a data item during an interval called the throttle time. At the end of this interval, Liberator sends just the latest updated values of the item to the subscribed clients. So the rate at which updates are sent to clients is reduced or “throttled”.

The following table shows in more detail how this works.

Consider a data item containing the bid and ask prices for stock in company ABC. Clients are subscribed to the stock item of subject /ABC consisting of two fields "bid" and "ask" (the bid price and the ask price). The table shows the succession of field updates that Liberator receives from the price feed via a Pricing Adapter, the values that it holds in its cache, and the throttled updates that are actually sent to clients subscribed to /ABC.

Time Updates received by Liberator /ABC
in Liberator cache
Updates sent to clients
    bid =    ask =  
Start of
throttle period 1
  51.160   52.032  
T1 bid=51.162, ask=52.037 51.162   52.037  
T2 bid=51.155 51.155   52.037  
T3 bid=51.158 51.158   52.037  
End of
throttle period 1
  51.158   52.037 bid=51.158, ask=52.037
Start of
throttle period 2
  51.158   52.037  
T5 ask=52.041 51.158   51.041  
T6 ask=52.040 51.158   51.040  
End of
throttle period 2
  51.158   51.040 ask=51.040

During the first throttle period the bid price changes three times (at times T1, T2, and T3) and the ask price changes just once (at time T1). At the end of this throttle period (time T4) Liberator sends just the most recently updated bid and ask prices to the clients, so the clients don't see the bid price updates at times T1 and T2.

During the second throttle period the ask price changes twice (at times T5 and T6), but the bid price doesn't change at all, so at the end of this period (time T7) Liberator sends only the most recently updated ask price to the clients.

If an item isn't updated at all during a throttle period, the very next time the item is updated in any subsequent throttle period Liberator immediately sends the updated values to its subscribed clients. This ensures that throttling doesn't introduce unnecessary delay in propagating updates to clients.

You can configure throttling per data item; this allows all the items in a particular directory or even an individual item in a directory to be throttled by specific amounts.

Liberator can supply the same item to multiple end-users at different throttle levels. This allows users who need to view a large number of items, but who have low specification computers or slow network connections to the server, to receive data at a speed that suits their environment.

Client applications can change the level of throttling for specified items, groups of items, or all items globally.

In some older Caplin documents, throttling is sometimes called conflation.

See also: