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 =


51.160 52.032

Start of throttle period 1


bid=51.162, ask=52.037

51.162 52.037



51.155 52.037



51.158 52.037


51.158 52.037

bid=51.158, ask=52.037

End of throttle period 1

Start of throttle period 2


51.158 52.037



51.158 51.041



51.158 51.040


51.158 51.040


End of throttle period 2

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: