Understand fundamentals of messaging so you can understand how to improve performance for this payload protocol.
With messaging payloads there is a trade off between efficiency
and immediacy. Some messages arrive earlier than in entity-state replication because the payload is
spread out over many relatively small messages that are delivered individually, as opposed to being delivered as a
single large download. Therefore the goal of tuning messaging performance is to perform multiple transfers of small payload volumes quickly, in addition to keeping changes in the correct order.
The messaging use cases center around three primary phases in moving data between server
and client, each of which need to be considered when choosing performance setting values. Each phase describes mobility environment components, and how they affect performance: MBO development and data design, EIS data models and runtime servers, and SAP Mobile Server runtimes. These phases are:
- Initial subscription – A mobile application subscribes to an messaging package to receive data as “import” messages from
the server. Upon the receipt of the subscription request from the
device, the server checks security and executes a query against the cache database (CDB) to retrieve the
data set, which it then turns into a series of import messages to be sent to the device. The maximum message
size is currently fixed at 20KB. Increasing the maximum allowable size would allow the same amount of import
data with fewer messages. However, in some devices, large message size can trigger resource exhaustion and
failures.
The subscription phase is the most expensive or time consuming portion of the life cycle, especially for a
large initial data set. However, compared to entity-state replication payloads, messaging payloads can take longer to populate the data on the device database
because of the aggregation of fine-grained messages. This latency is due to the additional cost of providing reliability
to the delivery of every message. In addition, a significant amount of processing is incurred on both the server and the
client side to marshal messages. While this marshaling may not necessarily impact the server, it places a heavy burden
on the device, especially if the device is on the low end of the performance spectrum. The message import is also
limited by the device’s nonvolatile storage write performance.
- Subsequent Synchronization – Device-side data changes due to the user interacting with a mobile application. It
is important that you understand the unit of change. An operation with an associated tree of objects with
a containment (or composite) relationship is considered a unit of change. Changes are wrapped in a message
with the appropriate operation type: create or update. (The delete operation requires only the primary key that
identifies the root of the tree to be transmitted, rather than the entire object tree). Upon receipt of the message,
the server replays the operation against the EIS and returns a replay result message with one or more import
messages that reflect the new state of the data. Unlike replication, the unit of change is pushed to the device as soon as
the changes are ready, so subsequent synchronization is occurring in the form of many messages. As a result, the
synchronization happens over time as a stream of messages.
The subsequent synchronization phase addresses mobile devices sending CUD requests to SAP Mobile Platform and
receiving responses and updates as a result of the operations. In general, the limiting factor for performance is on the
EIS as the CUD requests are replayed. You may experience SAP Mobile Server performance issues if requests are spread
over a number of back-end systems. If the EIS response time is large, you may need to allocate additional threads to
replay requests concurrently against the EIS.
- Incremental Synchronization – The updates sent to the device as messages due to DCN from the EIS. DCN is the
most efficient way for a back-end system to notify SAP Mobile Platform of changes to data mobilized to the device (as
opposed to polling for EIS changes).Because messaging uses push synchronization to send out the updates as import messages to the
devices, each DCN normally causes updates to device data over the messaging channels, based on a configurable schedule within the server. The
main reason for this behavior is the concern for activity storms arising from batched DCNs where many granular
changes on the cache cause flurries of messages that might be better consolidated first on the server. Currently,
most EIS back-ends are not event-driven and DCNs are batched. Hence, having batched triggers
directly driving an event-based model can decrease efficiency without increasing data freshness.