Understand fundamentals of entity-state replication, so you can understand how to improve performance for this protocol.
Entity-state replication has two distinct operation and data transfer phases where only differences are transferred: upload (where only updates from the mobile
client to the server are integrated with data in the mobile middleware cache and pushed to the EIS) and download (where EIS delta changes are determined for, and supplied to, the specific client).
These phases are conducted as discrete transactions to protect the integrity of synchronization. Synchronizations are carried out within a single data transfer session, allowing for exchanges of large payloads. Therefore the goal of tuning performance for the replication payload is to ensure those transfers of large volumes are handled effectively and not to create bottlenecks in the runtime.
Considerations that affect performance can be separated into synchronization phases and architecture components.
Entity-state replication 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 SAP Mobile Server runtimes. These phases are:
- Initial synchronization – where data is moved from the back-end enterprise
system, through the mobile middleware, and finally onto the device storage. This
phase represents the point where a new device is put into service or data is
reinitialized, and therefore represents the largest movement of data of all the
scenarios. In these performance test scenarios, the device-side file may be
purged to represent a fresh synchronization, or preserved to represent specific
cache refreshes on the server.
For this phase, the most
important performance consideration is the data and how it's partitioned
(EIS design), and loaded by the MBO (MBO development) using operation
parameters, synchronization filter parameters). Synchronization parameters
determine what data is relevant to a device; they are used as filters within
the server-side cache. Load parameters determine what data to load from the
EIS into the
cache.
- Incremental synchronization – involves create, update, and delete (CUD)
operations on the device where some data is already populated on the device and
changes are made to that data which then need to be reconciled with the cache
and the back-end enterprise system. When create and update operations occur,
changes may be pushed through the cache to the back end, reads may occur to
properly represent the system of record, for example, data on the back end may
be reformatted, or both. This scenario represents incremental changes to and
from the system of record.
As in the initial synchronization
phase, the EIS accounts for the bulk of the device synchronization response
time: a slow EIS consumes resources in the
SAP Mobile Server,
with the potential to further impede devices that are competing for
resources in connection pools. Additionally, the complexity of the mobile
model, measured by the number of relationships between MBOs, has a
significant impact on create, update, and delete operation performance.
Shared partitions among users or complex locking scenarios involving EIS
operations can become a major performance concern during device update
operations. Cache and EIS updates are accomplished within the scope of a
single transaction, so other users in the same partition are locked out
during an update of that partition. Consider denormalizing the model if
complex relationships cause performance concerns.
- Data change notification (DCN) – changes to the back-end data are pushed to the
mobile middleware and then reconciled with the device data. DCN is typically
observed in the context of additional changes to the device data so that changes
from both device and back end are simultaneously impacting the mobile middleware
cache.
DCN efficiently updates the
SAP Mobile Server
because it does not require the SAP Mobile Server to poll the EIS or to refresh
the cache based on a schedule. EIS DCN applied to the cache is independent
of the client synchronizations. If DCN data is located in a shared
partition, multiple devices benefit from the single EIS update to the cache.
There are several ways to materially improve DCN performance:
- Use a load-balancer between the EIS and the cache –
DCNs can be efficiently applied across
a
cluster, as each node in the cluster helps to parse incoming
payloads.
- Combine multiple updates into a single batch.
- Run DCNs from a multithreaded source to parallelize
updates. Note that there is a diminishing return beyond three to
four clients, in large part due to the nature of the model.
Different models exhibit different performance characteristics when applying updates,
so proper analysis of application behavior is important.