Messaging tuning recommendations are designed to maximize throughput of messages, as there are unique implications to using messages
as the medium of data exchange. The messaging processing limit (throttle) is determined by the number of inbound message
queues. Any Unwired Server within a cluster can process messages on inbound queues. The number of inbound
queues is equal to the number of parallel messaging package requests that the cluster can concurrently service.
Sybase recommendations touch on components outside and inside the LAN:
- Add multiple server nodes to increase data marshaling. Testing has indicated that one Unwired Server node is capable of sustaining around 70 messages per second
to devices. A second Unwired Server node provides an additional 60% increase in delivery capability. This increase
is because the second messaging node increases message marshaling and transmission capability for the entire device
population.
- Device performance and number of devices deploy. Device processing capacity limits the capacity of each message to 20KB. Due to serialization of data to JSON,
a roughly 2X increase in size is observed within our data model, i.e. 4MB worth of data is represented by 9MB of
serialized information for packaging into messages. As a result, the number of import messages is in the low 400s.
The 2X factor is only an estimate for a moderately complex application; the true cost depends on the number of
attributes (and the datatypes) of each MBO in the model. Furthermore, if push messages
are to be generated for a device, you should tune the environment after executing download SQL queries against the cache: the cost of the query depends
on the complexity of the download logic (number of MBO relationships) in addition to synchronization timestamp
comparison. For a large number of devices, this cost can be considerable.
- Approach initial synchronization carefully, and follow a sound rollout policy for new mobile applications.
The easiest approach is to spread the rollout over a period a time to avoid a large number of devices attempting
to download large amounts of data. Excessive load not only slows the rollout, but may also impact performance
for existing messaging applications. Apart from Unwired Platform capacity and connectivity bandwidth, the actual time
required to perform the initial synchronization depends mostly on the capability of the device.
- Allocate additional threads to
replay requests concurrently against the EIS. Choosing a value depends upon:
- The number of concurrent CUD operations that an EIS can handle without causing degradation
- The number of simultaneously active EIS operations the load is spread across
- The average response time for various EIS operations
- Any lock contention points in the mobile model that exist due to shared data partitions
- The total application landscape (Unwired Platform does not
assign threads on a per package basis. All threads are available to service CUD operations for any of the deployed
messaging packages.)
- The Unwired Server data change check frequency for each package. The higher the check frequency, the higher the cost, but data freshness may not
actually increase. The gating factor is the frequency of updates from the EIS. If the cache is configured to refresh at
midnight, after the EIS performs certain batch processing, it is most efficient to configure the scheduler to check for
changes sometime after the cache refresh is completed. For an EIS that uses DCN to update the cache, the amount
and frequency of changes depends on the business process. Understanding the data flow pattern from EIS to cache is
crucial to determine how frequently the Unwired Server is to check for changes to be pushed to the devices.
- Batch multiple DCN updates in a single notification to reduce overhead. However, a batch that is
too large may impact device synchronization response due to contention. A storm of DCNs can create significant work
for devices. The tradeoff is efficiency versus performance (responsiveness).
- During the packaging of data into messages, serialization consumes a significant amount of memory. Monitor gargage collection activities for Unwired Server. If required, configure JVM heap settings to minimize garbage collection, especially during messaging application deployments and initial synchronizations.