Persistence Rules
| Client Performance Guide | Performance
API
Developing for Performance
Introduction
Performance is crucial for business applications in general, but even more
so for mobile applications. Surveys show that end-users experience performance
as key in the whole user interaction on mobile devices. SAP Mobile Infrastructure has
been designed with performance in mind, but application developers need to apply
general Java rules and mobile-specific recommendations to get most out of this
platform.
In this chapter, we will
- discuss all performance-relevant
components of your mobile solution individually and point out what application
developers can do to improve the performance of each component. We will then
- derive general performance rules for mobile
application developers
In the Persistence chapter, we laid done specific rules
for best handling of the Persistence API. These rules also effect best handling
of the Smart Sync API, as Smart Sync itself uses the Persistence API for data
storage and retrieval.
Mobile Solution Performance
The overall performance of your mobile solution on MI is dependent on a multitude
of factors. The grafic below displays the central points of research and we'll
then discuss their performance effect:

- MI-based applications can use an AWT UI ar a browser based UI. Performance-wise,
the page rendering of the browser adds up to the overall performance of the
mobile application
- The client-side of the mobile application is developed in Java. Standard
Java rules should be observed for increasing performance, lowering memory
consumption and reducing the runtime of garbage collection.
Application developers should refer to standard literature
on Java performance like, for example, "Java Platform Performance"
by Wilson/Kesselman. For analyzing your application, standard profiling tools
like the Eclipse
Profiler Plugin can be used to detect performance bottle-necks.
- The SAP MI Client has been designed and analyzed carefully with performance
in mind.
- SAP has worked closely together with JRE vendors to boost JRE performance
on the Microsoft PocketPC platform. If your target operating system is Microsoft
PockePC, please make sure to use the latest JRE from the Mobile Infrastructure CD.
- SAP has put special care into the design and runtime of MI's persistence
layer. The persistence layer can be used explicitely through the Persistence
API or implicitely through the Smart
Sync API (which itself uses Persistence API to store its data).
The MI Persistence layer can store data on the file system or on a locally
installed data base. Database persistence is recommended if your application
is using a lot of data.
Application developers should observe special rules
when using both API.
- The operating system and the hardware of the device play a major role overall
device performance. Microsoft PocketPC 2003 has made major steps to increase
OS performance, while at the same time chipsets have contributed their share
to overall performance.
- Data exchanged between MI Client and MI Server can dynamically be compressed
bi-directionally. This feature should always be enabled in live environments.
If your application is using Smart Sync, MI automatically determines what
data has been changed on either side and makes sure that only minimal data
is exchanged.
Still, application developers should make sure that only relevant data is
synchronized by designing their SyncBO
or wrapper functions accordingly,
that means by limiting the number of transferred fields and by choosing the
SyncBO
type that best suits your business scenario. It is recommended to always
use asynchronous processing of synchronized data, which is also the default
in both Generic Sync and Smart Sync.
Administrators can lower data load by carefully assigning the right data to
the right devices in the Smart
Sync Adminstration Toolkit.
- By choosing SAP Web Application Server as its middleware, MI automatically
uses the same scalability and sizing
concept as the WebAS. Smart Sync replication has been carefully analyzed and
tested for performance as well.
Application developers should make sure to limit the size of the Smart Sync
Replica DB by carefully designing their SyncBO and wrapper functions.
Administrators can increase Smart Sync Performance through various factors
like defining the maximum number of handlers and senders and by purging old
Smart Sync data on a regular basis. Furthermore, the WebAS should be sized
according to your business scenario and data load. Sizing mySAP Mobile
Business at /sizing
can serve as a guideline for sizing of your custom application.
- Replication between MI Server and application backend uses standard RFC
technology for data transfer. Application developers should again make sure
to lower the amount of data between these two systems by designing the Smart
Sync BAPI Wrappers and Generic Sync wrapper functions accordingly.
- For performance guidelines for the backend-side of your application, please
refer to the Performance Homepage
on SAP Service Marketplace. For performance tips for client programming, refer
to the client performance guide.
Performance Rules for Mobile Applications
Keeping the above discussion of the full mobile solution landscape in mind,
we can derive these performance rules for mobile applications:
- Keep data load low
Be aware of the ressource constraints of your mobile device
and design your application accordingly. Do not simply port your business
scenario to the mobile device, but specifically design your mobile application
for the target device while keeping in mind its limited ressources. The following
concrete steps can be taken to this goal:
- Limit the data transfer between WebAS and application backend
To this end, you can design your BAPI Wrappers (Smart Sync) or Wrapper
Functions (Generic Sync) accordingly. Both should only transfer fields
that are either required on the WebAS (for example for data assignment
to users) or on the mobile device (for business logic or screens). The
SyncBO type also determines when and how often data is transferred between
WebAS and backend and should be chosen carefully. This will help to reduce
the network load and the load on the WebAS database.
- Limit the data transfer between WebAS and devices
To this goal, design your SyncBO to only expose fields to devices that
are actually required in the mobile applications. Smart Sync itself will
take care of delta management. In case of Generic Sync sync, you'll need
to compute deltas yourself in the your wrapper functions.
SAP standard applications observe this rule and have been sized for ideal
performance. SAP's Mobile Asset Management for Handheld, for example, is
designed for a typical data load like the following: 10 service orders per
technician, where each order includes 3 business partners, one functional
location, one notification, 5 operations, one equipment and 5 materials.
Additionally, every technician has an average of inventory count of 100
materials. These figures together with an assumed frequency and concurrency
of synchronizations lead to the sizing figures published in Sizing mySAP
Mobile Business that can be found in the Media Library at at alias
/sizing on SAP
Service Marketplace.
- Keep connectivity times short
- By default, MI just delivers the client's outbox to the MI Server during
synchronization and picks up the server's outbox. Processing of Generic
Sync containers and the Smart Sync messages will be done later by a background
job (Generic Sync) or in a background process (Smart Sync). Application
developers can request immediate processing of data containers by creating
containers of type
OutboundContainer.TYPE_REQUEST
(Generic
Sync) or by requesting synchronous
processing via the Smart Sync API.
Synchronous processing will seriously effect the overall synchronization
time and should always be avoided, because the processing time for the data
fully adds to the synchronization time. Always keep in mind that your application
might not be the only application running (and synchronizing) on the device
and that the connection may be of low bandwidth. To date, there is no way
for developers and end-users to define and restrict which data of which
application is synchronized and end-uses will seriously dislike long synchronization
times. Eventually, long synchronization times may even lead to browser time-outs
and thus to unsuccessful synchronizations.
- MI dynamically compresses synchronized data, if compression is switched
on on client and WebAS (J2EE side). By default, compression is turned off,
but addministrators should always ensure that compression is switched on
by the corresponding steps in the MI installation guide (see /instguides
on Service Marketplace)
- Best use of MI Client API
The rules laid down for the Persistence
API and performance tips should be followed
carefully to make best use of this API (and also for Smart Sync API).
- Memory = Performance !!!
On PDA, application performance is almost equivalent to the memory consumption
of the application. This is due to the fact that garbage collection eats up
a major part of the overall runtime of your mobile application. The more memory
is allocated by your application, the longer the garbage collection will run
needlessly in order to free precious memory of your device. Please use standard
Java rules for limiting memory consumption, early releasing of memory and
follow the rules laid done for the Persistence API..
- Java Performance Guidelines
At the end of day, mobile apps are still normal Java applications and should
be designed, analyzed and optimized just as other Java applications. Standard
literature and tools (see above) will
help you to develop for performance.
If you are using JSP as UI and your customers do not need to modify the JSP,
then you should precompile your JSP on export
with the MDK Plug-In. Compilation on the device takes a lot of time on
first call of the JSP leads to less performant compiled code than compiling
the JSP beforehand with the MDK Plug-In.