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

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:

  1. 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
  2. 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.
  3. The SAP MI Client has been designed and analyzed carefully with performance in mind.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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: