Mobile Synchronization Scalability and Performance for the Oracle Mobile Field Service Store and Forward Applications

Performance Tuning of Mobile Application Framework

To achieve the test results described in this appendix, tune the Mobile Application Foundation as described in this section. Here, performance tuning issues specific to Oracle Mobile Field Service Store and Forward are addressed. The following figure illustrates the Oracle Mobile Field Service Store and Forward architecture.

the picture is described in the document text

The first or initial synchronization, from the mobile computer device installs the entire Oracle Mobile Field Service Store and Forward application as well as the data targeted for that mobile user. Subsequent synchronizations (also called incremental or fast synchronizations) only download application upgrades and incremental data. This incremental dataset consists of data updated on the mobile computer device since last synchronization and data ready on the server since the last synchronization. It can be expected that in a live or production instance, application upgrades are minimal and therefore incremental synchronizations mainly transfer new data. Synchronizations that do not involve either application upgrades or data transfer are called null synchronizations. Null synchronizations are useful for performance benchmarking since they provide the lowest possible synchronization time.

First-time synchronizations should be done on either a LAN or network with a high bandwidth so that the synchronization completes in a timely manner. First-time synchronizations over low-bandwidth (GPRS) networks can terminate due to low network time-out settings. In this case, the latency for preparing a first-time synchronization dataset could require minutes as opposed to seconds for subsequent synchronizations. If the first-time synchronization fails, the process must restart from the beginning.

You are not expected to tune the Oracle Mobile Field Service Store and Forward application on the mobile computer device, except to ensure that the minimum system requirements are met.

Administrators should use the following to assess system performance:

Database Tuning

Mobile Field Service Store and Forward captures online business activities such as service request creation and task assignments and then downloads this data to the mobile users. Mobile Field Service Store and Forward uses concurrent programs to find and prepare this data. Data that is prepared for synchronization is stored in the out queue. The out queue comprises two tables: ASG_SYSTEM_DIRTY_QUEUE and ASG_DELETE_QUEUE.

Tuning Out Queue

Better synchronization times can be achieved by tuning the out-queue. The out-queue performance is constantly being improved by tuning the queries executed on the out-queue tables. Since the tables are insert/delete intensive, one of the important storage parameters is PCTUSED. For best performance, set this parameter to a high value like 70%. The size of the out-queue is related to amount of business activity relevant to mobile. Data prepared in the out-queue is automatically removed after the mobile device receives it.

There are several indexes defined in the ASG_SYSTEM_DIRTY_QUEUE table that eliminate the need for full table scans and optimize access. However, it is recommended that these indexes be managed carefully. Due to the insert/delete intensive nature of data management languages (DMLs) on this table, index-stagnation could become an issue. This will result in longer synchronization times even though the size of ASG_SYSTEM_DIRTY_QUEUE table remains about the same. In this case, index-rebuilds have proven to be helpful.

It is possible to purge the out-queue for dormant users by scheduling the JTM Master Concurrent Program with category type "purge." This will purge records for dormant users. Dormant users are those who have not synchronized for the past N days, where N is the value of profile option, ASG: Dormancy Period. The JTM Master Concurrent Program will also remove any duplicate records in the out-queue. For best performance, schedule this program once every week.

Tuning Concurrent Programs

For mobile operations, mobile concurrent programs place a big demand on the database, even more so than synchronization. The JTM Master Concurrent Program is a good example of this. For this program, you must run three category types: Transaction, Lookup and Inventory. You should regularly monitor the times taken for each category type. You can use the following table to do this.

Category Type Scheduled Interval Average Run Time
Transaction 5 min  
Lookup 1 hour  
Inventory 1 day  

The actual scheduled interval for these programs depend on your business requirements. However, the average run time should be compared with the scheduled interval to make sure that it is a very small fraction of the scheduled interval (less than 5% for Lookup and Inventory, and 20% for Transaction). If the concurrent programs take a longer time, then increase the scheduled interval so that the system is not overloaded.