S

I E B E L

Y S T E M S

N C

Siebel Handheld v.7.0.4 Synchronization Technical Note 06-17-2002

Table of Contents:
1. 2. Introduction ................................................................................................3 Siebel 7 Handheld Synchronization Enhancements....................................3 2.1. Data Compression ..............................................................................3 2.2. Asynchronous Transaction/Extraction Processing (Available as the BatchSync TAM Tool) ...................................................................................4 3. Recommended Hardware and Network Configuration ...............................4 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. 4. Server Architecture ............................................................................4 Server Hardware and Registry Parameters ......................................5 Database Server Sizing.......................................................................6 Database Tuning.................................................................................6 Dial-Up and Network .........................................................................7 Wireless...............................................................................................7 VPN (Virtual Private Networks)........................................................7

Application-Specific Variables Affecting Synchronization .........................8

5. Handheld Synchronization Performance and Scalability Benchmark Cases ...................................................................................................................8 5.1. Case 1 Full Synchronization of 150 users, 150 transactions...........9 5.2. Case 2 150 users, 2800 transactions w/ Asynchronous Upload/Download...........................................................................................9 5.3. Profile of Hardware Used in Performance and Scalability Testing 11

1. Introduction
One aspect of successful Siebel Handheld Direct Server Synchronization (DSS) deployment is to focus on server hardware and network requirements. This Technical Note provides an overview of important considerations when planning DSS infrastructure. As there are unique aspects to each customer configuration and implementation s strategy, it is highly recommended that customers conduct detailed configuration, sizing, and production readiness reviews with Siebel Expert Services (see mandatory service offerings in the next paragraph). This is especially important for complex deployments, such as those supporting large numbers of users or over a wide geographic area. For each new customer deployment of Siebel Handheld, there are mandatory Siebel Professional Services Programs called: The Siebel Mobile eBusiness Competency QuickStart Engagement and/or The Siebel Expert Services Handheld Implementation Program. For more information about these programs, contact Siebel Professional Services or your Technical Account Manager.
NOTE: The recommendations in this technical note are for general information only and are intended to raise the awareness of key elements and considerations for Siebel Handheld synchronization performance and scalability. This information is not intended to replace Siebel Mobile eBusiness Quickstarts nor Siebel Expert Services Reviews.

--------------------------------------------------------------------------------------------------------------

2. Siebel 7 Enhancements

Handheld

Synchronization

In Siebel 7 Handheld v.7.0.4, a number of enhancements have been introduced to improve the performance and scalability of Siebel Handheld Synchronization.

2.1.

Data Compression

The Handheld Synchronization process provides compression of the communication stream between the server and the handheld client to minimize the time required for a direct server synchronization (data compression is not used for companion synchronization). The synchronization software compresses both the extracted data file and application metadata file during download to the handheld client, and the transaction data during upload. Please note that memory usage will spike briefly as

files are uncompressed. While the actual benefit from compression depends on the type of data extracted, compression generally reduces the data transferred between the handheld client and server on the order of 60-80%.

2.2. Asynchronous Transaction/Extraction Processing (Available as the BatchSync TAM Tool)

This function allows customers the ability to run an asynchronous data extraction process (upload only and download only sync sessions). This function is not recommended for general use as the likelihood of sync errors increases with the length of time between an upload and download process. For example, a common error would be a conflict due to a change on the Handheld or on the Server for a record that has already been uploaded. For process controlled synchronization sessions, when enabled, this allows end users to upload their Siebel Handheld transactions at the end of the day. Overnight, the administrator initiates an automatic process to generate new extracts for all users. When they return in the morning, users download the new extract and are prepared for the day. This utility targets Siebel Handheld customers whose end users typically log high numbers (>1,000) of transactions each day. Please contact your Technical Account Manager or Siebel Technical Support for information on this synchronization option.

3. Recommended Configuration
3.1.

Hardware

and

Network

Server Architecture

Customers should dedicate server machines for Direct Server Synchronization as outlined below. If additional applications require server resources, consult Expert Services for guidance: One dedicated machine for Siebel Web Server sized to accommodate peak concurrent Synchronization loads. Typical sizing is 2 x 700 Mhz Intel Pentium III Xeon processor machines with 1 GB RAM, including disk space for Siebel Web components and Microsoft IIS and enterprise-class availability features. One dedicated machine to host the Siebel Gateway Server, Siebel File System, Siebel Workflow Manager, Siebel Assignment Manager, and Enterprise Integration Manager (if applicable).

 One or more machines to support the Handheld Siebel Object Managers. As a general rule, you should size the Siebel Application Servers to allow 64 MB of Application Server RAM per concurrent process. It is optimal to run at a ratio of two threads per process. Note that multiple Siebel Object Managers must be statically load balanced through the use of separate virtual DSS URLs that in-turn point to different Siebel Servers.
NOTE: To calculate maximum number of users and associated required memory,

use the following formula: MaxNumusers = (Server Memory * threads per process ratio) / 64MB.

3.2.

Server Hardware and Registry Parameters

L2 cache size. In addition to the number and speed of CPU customers should s, maximize the L2 cache size of their server hardware. Manufacturer. Customers should note that equipment from different manufacturers can perform differently under similar use. Physical and virtual memory. It is advised that customers maximize physical and virtual memory. Disk speed and array caching. Higher disk speed and array caching can both improve performance. Network cards. Configuring systems with multiple, high-speed network cards increases the bandwidth of communications and can improve synchronization performance. NDIS settings. Some multiprocessor servers can dynamically distribute networking I/O requests to the least busy processor. Distributing these requests has resulted in increased network performance during handheld synchronization scalability testing on multiprocessor systems that are under very heavy CPU load (i.e. near 100% CPU utilization). By default, in both NT4 and Windows 2000, the Network Interrupts are assigned to the highest number cpu in the system. The change detailed below allows these interrupts to be distributed dynamically to the least busy cpu in the system. On a multiprocessor server that is capable of distributing networking I/O requests, set the value of the following parameter to zero in the Windows registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NDIS\Paramet ers\ProcessorAffinityMask

3.3.

Database Server Sizing

Database server sizing is a key factor in the overall performance of Direct Server Synchronization concurrent synchronizations. Be aware that the database sizing profile for Siebel Handheld varies from other Siebel applications because the database interactions follow a different pattern. With most Siebel applications, users interact with the database at an even, relatively low pace throughout the usage period. With Siebel Handheld, captured transactions are applied to the database in rapid succession. As a general rule, approximately 70 MB of database server memory per concurrent synchronization should be allocated. Since the performance of handheld synchronization depends on numerous customer-specific factors, such as Siebel application configuration, server database volume and software, and the use of clustering software, customers should closely monitor database server performance as they perform synchronization testing. Database tuning is recommended to remedy slow queries, which can adversely impact handheld synchronization performance.

3.4.

Database Tuning

Below are some additional guidelines for database tuning: When adding hardware to a database server, adding physical RAM provides the greatest overall performance improvement. For best database performance, make sure that the Buffer Cache Hit Ratio is 90% or higher. The closer this value is to 100%, the more data is stored in cache and the faster the database server. This is because less disk I/O is required. If using MSSQL Server, try to limit the amount of RAM that SQL Server can access. This helps reduce memory conflicts with the operating system and thereby reduces the amount of memory paging. Use RAID 0 + 1 disk array and increase the number of spindles to improve disk read/write performance. Search for long running SQL queries and improve performance by creating new indexes.
NOTE: As a general practice, monitor CPU and memory consumption using Microsoft

Performance Monitor, which is included with Microsoft Windows NT/2K.

3.5.

Dial-Up and Network

When users synchronize using Direct Server Synchronization, they create an HTTP connection to their corporate network. This connection must be made through a wireline modem or through a direct LAN connection. The complete network must be analyzed for network bottlenecks. For example, an office is using a 56 Kbps leased line connection with end users dialing into a regional ISP. If 50 users are concurrently synchronizing 1 MB each, 50 MB of data must pass through the network. If this data is passing through a single leased 56 Kb/sec line, then this data will minimally take 500,000 Kb/56 Kbps=8928 seconds=148 minutes. In reality, a 56 Kbps line will offer only 30-40 Kbps average throughput which causes further bandwidth constraints. Check total available bandwidth of network providers (private or public ISP). Some other dial-up and network considerations include the following: Make sure you have adequate bandwidth throughout the entire round trip of network packets, estimating where bottlenecks will occur due to high concurrent load. Make sure you have low latency lines with ping round trips of less than 1 second (1000 ms) with no dropped packets. Minimize hops through improved routing. Make sure that the Servers (IIS, GW, OM, and DB) are on the same high speed LAN segment.

3.6.

Wireless

Wireless synchronization is not recommended or supported.

3.7.

VPN (Virtual Private Networks)

VPN solutions are offered by 3rd party companies such as V-One and Certicom. Siebel Systems has not validated any 3rd party VPN solutions and makes no claims nor warranty as to the efficacy or successful integration of Siebel Handheld and these VPN solutions. VPNs can add as much as a 50% incremental overhead to the packet load due to the encryption scheme. Further, additional processing CPU power is used to encrypt and decrypt data packets. Impact on sizing servers and networks should be referred to the third party VPN vendors.

4. Application-Specific Synchronization

Variables

Affecting

In addition to the factors outlined above, a number of other issues must be considered when planning a Direct Server Synchronization deployment. These include: Size of data extract. The larger the data extract, the longer the time required to process and download the extract. The size of the data extract can be determined by looking at the size of the dbfile.txt file in the handheld user folder on the server. Filters are used to reduce the data extract size. Volume of transactions processed. A transaction is defined as an interaction with a record that results in a change to the handheld database. When users make such changes on the handheld, these transactions are captured in a log. The first step of synchronization is to upload this transaction log and apply the transactions to the server database. This is a processor-intensive operation, so the fewer transactions processed during each synchronization event, the shorter the overall synchronization time. Therefore, users should synchronize frequently and avoid going for long periods of use without synchronizing. Number and timing of users. The number of peak concurrent synchronization users and the pattern of usage are critical in determining the appropriate sizing for the synchronization infrastructure. For example, a much larger population of users can be supported for a given server when the users synchronize throughout the day versus a group that all synchronizes within a small time window each day. Complexity of application. In general, the simpler the Siebel Handheld application, the shorter the synchronization time. A simple application is one that includes fewer Screens, Views, Applets, and Fields. Support of Unicode. Unicode implementations can expect an incremental 1015% increase in sync times.

5. Handheld Synchronization Performance Scalability Benchmark Cases

and

The cases below illustrate examples of Handheld Synchronization performance and scalability achieved in a lab environment at Siebel Systems. The profile of hardware

used for these test cases is provided below. As stated above, the sizing of hardware required to support a given customer environment depends on a variety of factors. These results are provided as reference points only for customers as they begin evaluating their Siebel Handheld deployment.

5.1. Case 1 Full Synchronization of 150 users, 150 transactions

This case represents the typical, full Handheld Synchronization process that includes transaction upload and data/metadata extraction. In this case, the user population of 150 individuals synchronizes over a two-hour period; the synchronization start times follow a normal distribution. This is a likely scenario for white collar sales deployments, where userswork patterns are similar, but not defined by rigid start and end times. For this test case, the volume of data on the handheld is 1.0MB, and the users generate 150 transactions between synchronization sessions. Extract Size Transactions Users Application Complexity Timing of Users period Network Connection Synchronization Time 1.0MB 150 150 Highly complex Start times are normally distributed over 2-hr Simulated 56 Kbps modem connection Average: Minimum: Maximum: 9.6 minutes 5.1 minutes 14.7 minutes 2.2GB (NT)

Max. Memory Consumed by HH Sync Processes:

5.2. Case 2 150 users, 2800 transactions w/ Asynchronous Upload/Download

This case illustrates the use of asynchronous upload and download by users with

very high transaction processing requirements. In this example, users interact with the Siebel Handheld application during the day, creating a large number of orders, invoices, and records relating to retailerson-hand inventory, store displays, etc. The synchronization process is broken into three distinct phases, as follows: End of day users choose to Upload Only their transactions. As soon as the data transfers from the handheld to the server, the user is disconnected. The device is then put into a charger for the night. Although the user disconnects, the handheld transactions are immediately processed and applied to the Siebel Server. For example: o 150 users enter several depots over two hours. 70% of them enter in the first hour and 30% enter in the second hour. During both hours, the rate of entry is a bell-curve distribution.

Overnight Extraction the administrator schedules a batch extraction to occur during the night. When the extraction runs, a new data file is created for each user. This file is stored on the server until the user connects in the morning. Morning all the users connect at roughly the same time in the morning and choose to Download Only Each user data file is downloaded to the . s device and imported into the handheld database. The user is now ready to complete the day activities. s For this test case, the volume of data on the handheld is 2.0MB, and the users generate 2,800 transactions between synchronization sessions. Extract Size Transactions Users Application Complexity complex Timing of Users second hour Network Connection Synchronization Time 2.0MB 2,800 150 Siebel eConsumer Goods Handheld highly 70% of users in first hour, 30% of users in Simulated 56 Kbps modem connection User upload time (average): 9.6 min.

Transaction processing (NT): Transaction processing (Win2K): Overnight Extraction: Data download: Max. Memory Consumed by Handheld Sync Processes: 3.4GB (Win2K) Maximum Database Server CPU Utilization:

3 hr., 3 min. 3 hr., 32 min. 26 min. 7.3 min. 3GB (NT),

5% (NT), 13% (Win2K)

5.3. Profile of Hardware Used in Performance and Scalability Testing

App Server Server Hardware: Physical memory: Virtual memory: Operating System: SP2 Network: NDIS Setting:

4 X 700 MHz 3,883,352 KB. 11,694,732 KB. Windows NT 4.0 SP6, Windows 2000 Advanced Server 100 Mbps HKEY_ LOCAL_MACHINE\System\CurrentControlSet\Services\ NDIS\ Parameters\ProcessorAffinityMask = 0

Web Server Server Hardware: Physical memory: Virtual memory: Operating System: Network: DB Server Server Hardware: Physical memory: Virtual memory: Operating System: SP2 Network:

2 X 866 MHz 2,096,660 KB 6,134,534 KB Windows 2000 Advanced Server SP2 100 Mbps

4 X 700 MHz 3,883,352 KB 11,694,732 KB Windows NT 4.0 SP6, Windows 2000 Advanced Server I00 Mbps