Deploying and Managing Apama Applications > Managing the Dashboard Data Server and Display Server > Controlling Update Frequency
Controlling Update Frequency
The correlator sends update events to the Data Server, Display Server, or any clients using the Scenario Service API, whenever the values of fields or output variables in your DataViews or scenarios change. If you have DataViews or scenarios that update frequently, you might need to reduce the frequency of update events sent by the correlator.
You can adjust settings per scenario definition or globally. The global value is used where a given scenario definition has no specific setting. The per-definition values always take precedence over the global values.
The com.apama.scenario.ConfigureUpdates event controls the sending of updates for all Apama-supplied monitors that the ScenarioService can be used with (that is, scenarios as generated by Event Modeler, DataViews, and MemoryStore tables with exposeMemoryView or exposePersistentView set in their schemas).
A ConfigureUpdates event consists of the following:
*scenarioId (type string): May be the empty string to modify the global values, or a definition’s scenarioId.
*Configuration (type dictionary (string, string)): Configuration key and values. Key can be one of:
*sendThrottled (type boolean): Whether to send throttled updates (on the scenarioId.Data channel). The default is true.
*sendRaw (type boolean): Whether to send every update (on the scenarioId.Data.Raw channel). The default is true.
*throttlePeriod (type float): Throttle period in seconds. A zero value indicates no throttling. The default is 0.0.
*routeUpdates (type boolean): Whether to route Update events for the benefit of MonitorScript running in the correlator. The default is false.
*sendThrottledUser: (boolean): Whether to send throttled updates on a per-user channel. The default is false.
*sendRawUser (type boolean): Whether to send raw updates on a per-user channel. The default is false.
Those with a User suffix are suitable for using with only custom clients that use ScenarioServiceConfig.setUsernameFilter() on their scenario service configuration.
For example, consider the following:
com.apama.scenario.ConfigureUpdates("Scenario_scenario1",
{"sendRaw":"true"})
com.apama.scenario.ConfigureUpdates("",{"sendRaw":"false",
"throttlePeriod":"0.1"})
com.apama.scenario.ConfigureUpdates("Scenario_scenario2",
{"sendRaw":"true"})
com.apama.scenario.ConfigureUpdates(Sscenario_scenario3",
{"throttlePeriod":"1.0"})
The above examples configure Scenario_scenario1 and Scenario_scenario2 to send raw updates; Scenario_scenario3 to use a throttle period of 1 second; and all other scenarios to not send raw updates, and to use a throttle period of 0.1 seconds.
Earlier releases used the com.apama.scenario.SetThrottlingPeriod(x) event. Note that the use of the ConfigureUpdates events allows greater flexibility than the SetThrottlingPeriod event (which only controlled sending of throttled updates for all scenarios).
The use of com.apama.scenario.SetThrottlingPeriod(x) should be replaced with

com.apama.scenario.ConfigureUpdates("", {"throttlePeriod":"x"})
Note that by default, routeUpdates is false, so any EPL that relies on Update (and other scenario control events) to be routed should route a ConfigureUpdates event for the scenarioIds it is interested in to route Updates. Note that scenarios exported as blocks will do this in the generated block code.
The latest values are always used — thus it is not advisable for a client to send an event requesting (for example) raw updates and then undo this when it disconnects, as that will affect other clients. The recommendation is that the administrator should configure settings at initialization time. routeUpdates is an exception, but be aware that scenarios for which a block is generated will route updates after a scenario using that block has been injected and deleted, which may not be absolutely required.
Runtime performance of scenarios and dataviews can be improved by setting sendRaw and routeUpdates to false and throttlePeriod to a non-zero value. In this case, the cost of an update is reduced (as the Update events are only generated when needed, and if throttling, they are only needed at most once every throttlePeriod).
Copyright © 2013 Software AG, Darmstadt, Germany and/or Software AG USA Inc., Reston, VA, USA, and/or Terracotta Inc., San Francisco, CA, USA, and/or Software AG (Canada) Inc., Cambridge, Ontario, Canada, and/or, Software AG (UK) Ltd., Derby, United Kingdom, and/or Software A.G. (Israel) Ltd., Or-Yehuda, Israel and/or their licensors.