SAP® Mobile Platform 2.3
Sizing Guide
Sybase® Unwired Platform 2.3 Sizing Guide
TABLE OF CONTENTS
INTRODUCTION ............................................................................................................................................... 4
FUNCTIONS OF SAP MOBILE PLATFORM ................................................................................................... 4
Online Data Proxy ...................................................................................................................................................5
SAP OData Applications ...........................................................................................................................................5
Architecture of the Online Data Proxy ......................................................................................................................6
Mobile Messaging Applications ............................................................................................................................7
Architecture of Mobile Messaging Deployment ........................................................................................................7
Mobile Synchronization Applications ...................................................................................................................8
Cache Synchronization Deployment ........................................................................................................................8
Cache Synchronization Architecture ........................................................................................................................9
The Cache ..............................................................................................................................................................10
Agentry Applications ............................................................................................................................................11
Agentry Runtime Application Instance ....................................................................................................................12
Back-End System Support......................................................................................................................................13
SIZING FUNDAMENTALS AND TERMINOLOGY ......................................................................................... 14
Sizing ......................................................................................................................................................................14
Benchmarking .........................................................................................................................................................14
SAP Application Performance Standard .................................................................................................................14
Initial Sizing .............................................................................................................................................................14
Expert Sizing ...........................................................................................................................................................14
Configuration and System Landscaping .................................................................................................................14
INITIAL SIZING FOR ODATA MESSAGING APPLICATIONS...................................................................... 16
Assumptions .........................................................................................................................................................16
Business Scenario ..................................................................................................................................................16
Data Object Structure .............................................................................................................................................16
Key Considerations for the Sizing Analysis ............................................................................................................16
Messaging Channel Sizing .....................................................................................................................................17
Effect of Payload Size on Server Sizing .................................................................................................................17
INITIAL SIZING FOR MESSAGING APPLICATIONS ................................................................................... 19
Assumptions .........................................................................................................................................................19
Business Scenario ..................................................................................................................................................19
2
Sybase® Unwired Platform 2.3 Sizing Guide
Data Object Structure .............................................................................................................................................19
Key Considerations for the Sizing Analysis ............................................................................................................20
INITIAL SIZING FOR SYNCHRONIZATION APPLICATIONS ...................................................................... 22
Assumptions .........................................................................................................................................................22
Business Scenario ..................................................................................................................................................22
Data Object Structure .............................................................................................................................................23
Key Considerations for the Sizing Analysis ............................................................................................................23
SUP Cache Sizing Guidance ...............................................................................................................................24
Online......................................................................................................................................................................24
Offline Download ....................................................................................................................................................25
Offline Upload .........................................................................................................................................................26
SUP-DOE Sizing Guidance ..................................................................................................................................27
Online......................................................................................................................................................................27
Offline Download ....................................................................................................................................................27
Offline Upload .........................................................................................................................................................28
INITIAL SIZING FOR AGENTRY APPLICATIONS ...................................................................................................... 29
Assumptions .........................................................................................................................................................29
Data Object Structure ...........................................................................................................................................29
Agentry Sizing Guidance .....................................................................................................................................30
Base Calculation (Object Key Transmission Overhead) ........................................................................................31
Fetch (Download) Calculation ................................................................................................................................32
Upload Calculation..................................................................................................................................................32
Example ..................................................................................................................................................................33
APPENDIX ...................................................................................................................................................... 34
Physical I/O Subsystems .....................................................................................................................................34
Network Latency ...................................................................................................................................................34
3
Sybase® Unwired Platform 2.3 Sizing Guide
INTRODUCTION
This document is for service providers and enterprises that plan to deploy SAP® Mobile Platform (SMP) and
need to understand the different technology options and sizing considerations. Prior to deploying the mobile
platform, you will need to make several technology decisions based on the requirements of your mobile
applications. These technologies impact downstream sizing estimates for each component of the system. This
paper helps define the questions and answers related to technologies and sizing that everyone should ask prior
to deploying SAP Mobile Platform. Making these assessments and decisions early in the process is essential in
ensuring a successful project rollout.
Sizing guidance for the mobile platform messaging and replication nodes and associated data tier nodes are
supplied individually when the data tier is to be deployed on its own host (see the white paper “Sizing
Fundamentals and Terminology” for more information on the deployment options). The SAP sizing numbers for
the mobile server and data tier must be taken together to account for the entire solution.
The memory requirements in the sizing guidance are suggested memory amounts for the respective tiers,
including the operating system. If the solution is deployed on a single host, combine the memory requirements
for both nodes. The Mobile Server minimum memory requirement for any single host is 8 GB. The memory
requirements for a deployment executing multiple synchronization phases are not cumulative—use the highest
value stated for any combination of phases. When a server is used for different purposes (for example, workflow
and synchronization), add the CPU and memory requirements together to obtain the required total for the
deployment.
When the mobile server and data tier nodes are deployed on different hosts and the sizing for a tier is shown to
be below the minimum, use the minimum system requirements as the guidance for each node. For example, if
you are planning a small deployment, and the tables show that the mobile server node requires 4 GB and the
data tier 4 GB, a single host installation requires 8 GB, because the system minimum for the server is 8 GB. In
this same example, a two-host installation requires 8 GB on the mobile server node and 8 GB on the data tier. In
a larger installation, the data tier may be stated as 16 GB, while the mobile server node is stated as 8 GB. In this
case, a single host installation requires 24 GB, and a two-host installation requires 16 GB on the data tier and 8
GB on each mobile server node.
FUNCTIONS OF SAP MOBILE PLATFORM
Individuals and businesses develop mobile applications for specific user needs. These needs vary from teams of
service workers who use ruggedized devices for industry-specific applications, to consultants who track time and
expenses on a mobile device, or require simple corporate approvals. SAP Mobile Platform supports these mobile
scenarios, as well as cross-industry applications, such as customer relationship management, human resources,
supply chain management, business intelligence, product life cycle management, and industry-specific
applications that are tailored for the service provider, chemical/pharmaceutical, and utilities industries. These
mobile applications all follow two broad patterns; the pattern used depends primarily on who is driving the use
4
Sybase® Unwired Platform 2.3 Sizing Guide
case:
• End users, looking for information, for example, in an employee or customer lookup
• IT or line of business (LOB), improving organizational efficiency and customer engagement, for
example, via a sales process enablement
These patterns inherently represent two broad categories of mobile applications, which may support operations
that are allowed only while connected to the network, or that have features to support operation while
disconnected. These two classes of applications differ significantly in functional and some nonfunctional aspects.
Mobile Platform brings one or more technologies together to provide support for a few major types of mobile
applications:

Hybrid Web Container applications:
o Cross-platform request/reply or lookup
o

Mobile workflow patterns
Native applications using synchronization:
o Agentry applications that are synchronized directly against the back end
o Mid-tier result-set cache synchronization
o
Support of data consolidation and distribution with the Data Orchestration Engine (DOE)

Native applications using the OData SDK:
o Request/reply or lookup and guaranteed notifications

REST-based OData applications built with any SDK
o Request/reply or lookup with device specific native notifications
1
The purpose and function of the major application pillars are discussed in more detail later in this document,
along with the major technology components that support them.
Online Data Proxy
SAP OData Applications
The SAP NetWeaver Gateway exposes OData with extensions that are specific to SAP. Unwired Platform
serves as the IT infrastructure in a production environment by:
1

Establishing formal registration of device application instances before accessing enterprise resources for
both on-line and off-line applications

Publishing device application specific settings configured by the administrator
DOE is not recommended for new development; it is supported for backward compatibility with existing applications. For new applications, use mid-tier
cache synchronization instead. DOE is not discussed in detail in this document; refer to the DOE and DOE-C product documentation for specific
information related to this technology.
5
Sybase® Unwired Platform 2.3 Sizing Guide

Blacklisting specific application instances

Delegating Internet authentication to third parties and supporting single sign-on (SSO)

Configuring and exposing specific white-listed services from the NetWeaver Gateway (with URL
rewriting)

Providing a central device application reporting source based on the exposed public “application”

Providing a device application notification hub (that uses proprietary messaging and is device specific)
Architecture of the Online Data Proxy
When device applications communicate with the gateway, they do so with a synchronous message interface
(providing their own retry capability for interrupted communications). The synchronous interface avoids message
queues on the device, in the middleware, and associated database disk I/O, and may allow horizontal scaling of
the middleware. The middleware provides two forms of communication with enterprise OData resources: SDKbased messaging and REST.
Figure 1. S AP M obile Platform OData Infr astructu re for NetW eaver Gatew a y
OData web content can be accessed from SMP via a REST interface (new in SUP 2.2) or via the traditional
messaging interface that was used in previous versions of Mobile Platform.
Device users may publish their logical device address to Gateway, allowing data change notifications to be
forwarded from Gateway to the platform middleware and onto the device. These notifications are guaranteed to
be delivered to the device. Device notifications may be registered over device platform-specific channels like
6
Sybase® Unwired Platform 2.3 Sizing Guide
APNS or BES.
An additional deployment option available starting with SUP 2.2 is the option of adding “scale-out” nodes
alongside application server nodes at install time. The application server node provides the full capacity of all
mobile services. The scale-out node’s purpose is to provide extra capacity for stateless request/response
services for OData. Other mobile service requests, such as workflow or synchronization, are delegated to the
application server node. Data change notification requests are not accepted on a scale-out node. Your sizing
considerations for scale-out nodes should be calculated accordingly.
Mobile Messaging Applications
SAP Mobile Platform provides mobile messaging technologies that enable mobile device users to interact with
an application in the Hybrid Web Container (HWC). The container is a native application with a Web browser
plug-in and built-in SDK for connectivity, optionally guaranteed messaging, caching, and security. There are
three types of interaction patterns within workflow and the container:

Server initiated “workflow” that starts with a device targeted message from the back end

Client initiated “workflow” that starts when the user invokes an MBO operation from within the container

Client operations to an MBO online cache group that do not go through the server cache, for example a
search
Architecture of Mobile Messaging Deployment
In the messaging architecture, the server initiated changes to back-end data are generally sent via data change
notifications (DCN), and result in the creation of messages that are sent to the messaging server for dispatch.
Spooled messages that meet a specified set of matching criteria are placed in a queue for processing by plugins to the messaging transformer component, which augment the message with application-specific data or
processing instructions.
7
Sybase® Unwired Platform 2.3 Sizing Guide
Figure 2. H ybrid W eb M essaging Ar chite ctur e
Once transformed, the augmented message may be queued for transmission to the mobile device when the
device next connects to the SUP server. A notification is sent to the device container where the application can
choose what action to take, such as connecting to the server. Once the device connects, data messages are
pulled from the server and stored in the device’s queue where they await the user’s actions. When a user loads
an in-box message, the appropriate form is loaded by the application, and the user may perform applicationprovided actions (such as approving an expense request).
The device user’s responses are sent back to the messaging server. Depending on the application, the response
action may be queued, or may result in a synchronous action; this behavior is different from outbound message
transformations, which are always queued. Regardless of whether the response action is queued or performed
immediately, the application communicates with the Unwired Server to perform the action’s unit of work.
Mobile Synchronization Applications
Synchronization applications provide transactional consistency between the mobile device, the middleware and
the back-end system. Mobile Synchronization applications work in both connected and disconnected scenarios
(connection to the middleware server is not required). There are two types of synchronizations applications.
First, SUP can operate in standalone mode using the cache database in SUP. Here SUP directly is updated and
updates the backend system (EIS). The second option, which is not recommended for new application
development, is to use the Data Orchestration Engine (DOE) to cache the mobile data instead of SUP. When
DOE is used, SUP forwards messages between DOE and the device.
Cache Synchronization Deployment
Cache synchronization allows mapping mobile data and service objects to SAP Remote Function Calls (RFCs)
using Java Connector (JCO) and to other non-SAP data sources, such as databases and Web services. SUP
used in a standalone manner for data synchronization utilizes an efficient bulk transfer and data insertion
8
Sybase® Unwired Platform 2.3 Sizing Guide
technology between the middleware cache and the device database.
In a cache synchronization deployment, the mobile application is designed such that the developer specifies how
to load data from the back end into the cache, then filters and downloads cache data using device-supplied
parameters. The mobile content model and the mapping to the back end are directly integrated. This coupling
between device and back-end queries implies that the back end must be able to respond to requests from the
middleware based on user-supplied parameters and serve up mobile data appropriately.
Cache Synchronization Architecture
The SUP server synchronizes data between the device and the back end by maintaining records of device
synchronization activity in its consolidated database, along with any cached data that may have been retrieved
from the back end or pushed from the device. The SUP server employs several components in the
synchronization chain:

Mobile channel interfaces — provides a conduit for transporting data from and to remote devices over
which data is replicated between devices and the mobile middleware.

Mobile Middleware Services (MMS) — arbitrates and manages communications between device
requests from the mobile channel interfaces to a form that is suitable for transformation to a common
MBO service request to the data services components.

Data Services (DS) — is the interface to enterprise data, operations, and the middleware cache

Notification channel – is the mechanism that responds to events from the middleware and sends
messages to the device based on changes to the middleware cache or events from the backend such as
OData subscriptions notifications or workflow data change events
Once a mobile application model is designed, it can be packaged and deployed to the SUP server where it
operates as part of a specialized middleware container-managed application package interfacing with MMS and
DS components. When a package is deployed, its associated database cache tables are created along with
database operations that manage that package’s cache data. The middleware cache helps alleviate load from
the backend system, especially when many devices are downloading data at once, but the backend remains the
system of record.
9
Sybase® Unwired Platform 2.3 Sizing Guide
Figure 9. S AP M obile Platform Cache S ynchronizatio n Ar chitecture
The Cache
Cache-based synchronization uses the cache as a record keeper of what enterprise data users have on the
device. While the cache is not the system-of-record, it allows the server to compare the last time cache elements
were updated with the time the specific data elements on the device were last successfully synchronized. This
mechanism allows the server to download only the elements that have changed since the last device
synchronization.
The cache is manifested in the consolidated database (CDB), which is a relational database management
system. The server, specifically the application package hosted in the application server, communicates to the
CDB through JDBC connection pools, which can be configured in the administration console.
Each package has its own cache, and the life cycle of the cache is the same as the package. If the package is
removed from the server, the cache is removed. Cache data can be shared or partitioned based on application
parameters defined in the MBO model. If an MBO definition loads data where two application users have
overlapping synchronization parameters, the users are sharing the same data. However, if the application model
defines the MBO load parameters in a way that makes the data unique to a user (for example, an employee ID)
then the cache is partitioned and not shared.
10
Sybase® Unwired Platform 2.3 Sizing Guide
The load rules and validity of several MBO’s can be made configured together within a cache group. Each
cache group has its own load and coherency (validity) settings. The middleware cache, or cache group, can be
configured to load in one of three ways:

Upon a user request to synchronize data to a device, the cache is loaded. This “on-demand” method is
the least desirable method as the device must wait for the specified cache data to load from the
backend. The cache can have a “coherence” window based on the last time the cache was loaded. If
the coherence window is zero every user request will cause the associated segment or partition of the
cache to be loaded on every request. If the request is non-zero and the request is within the coherence
window the request is serviced from the cache.

Scheduled cache refreshes pull data from the backend. This method is typically only desirable for
reference data since the parameters to load the cache must be configured outside the context of any
user parameters. This option is best used during dormant hours and only if a DCN is not available.

Data Change Notifications (DCN) pushes data to the middle tier via HTTP/JSON. This is by far the most
desirable method of loading the cache for either initial loads or subsequent changes. Initial loads using
DCN can be spread across multiple members of the cluster and subsequent changes are surgical and
proactive. Use this method to load the cache whenever possible.
When a device connects in order to synchronize, downloads (to the device) are retrieved from the middleware
database over the replication channel. Uploads (from the device), consisting of device initiated data changes
and operations, are passed asynchronously to the MMS component (with respect to the download) into JMS
Messaging Channel queues and replayed in their own thread against the data services interfaces to the back
end and the cache. By default, the upload of changes is independent of the download although the user may
configure the application to always download changes right away. This decoupling of upload and download is
2
referred to as asynchronous operation replay which is the default behavior .
Once the upload changes are applied to the backend any resultant changes, along with changes caused by
other systems, are ready for download. The download phase occurs as a result of device application
synchronization. The device application may be user initiated (users manually triggers a synchronization) or
because the application is programmed to respond to a middleware notification to synchronize.
Agentry Applications
The Agentry architecture provides 4th generation language development of client-side behaviors for a mobile
app, coupled with back-end synchronization logic in the language of the enterprise systems being mobilized.
Typical use cases for an Agentry application include mobile workflows with simple or complex business
requirements and rules, an intelligent client with native on-device data storage, and potential implementation-
2
Applications built prior to SUP 2.1 ESD 2 couple upload and download transmissions.
11
Sybase® Unwired Platform 2.3 Sizing Guide
specific configuration. Agentry also ships with, and supports, several out-of-the-box bundled applications, which
typically include:
o The ability to process a moderate-to-high volume of data
o Simple or complex user interface
o Online and offline support of application functionality and data access
o Potential for multiple system connections between the Agentry Server and enterprise systems, possibly
with different synchronization paradigms (for example, SQL, Java, and so on)
The Agentry software components of the SAP Mobile Platform include the Agentry Runtime Instance, which
serves as a proxy to back-end synchronization or requests, Agentry Editor, and the Agentry Clients. Each
component serves a specific purpose, and all work together to provide the overall software solution.
Figure 10. Agentr y environ ment w ithin S AP M obile Platform
Agentry Runtime Application Instance
The SAP Mobile Platform Agentry Runtime Application Instance is the component that invokes synchronization
logic for all production data between the back-end system and the Agentry Clients. The application instance in
the middle tier does not cache any production data. The application instance also distributes the application
metadata “definitions” published from the Agentry Editor that are executed by the device client through the
application instance.
12
Sybase® Unwired Platform 2.3 Sizing Guide
Back-End System Support
An Agentry Application Instance can synchronize data between one or more back-end systems for a single
application. With respect to enterprise system integration, an application can synchronize production data with a
single system, or with multiple back-end systems of varying types.
A single application can synchronize data with:
o A database system using SQL
o A Web Server, by making CGI requests and receiving structured XML data in return
o The Windows host system upon which the Agentry Server is running
o A Java API, using the JVM
o An SAP back-end system that supports Java Connector (JCO) technology
Each Agentry Application Instance can also connect to multiple back-end systems, including any one or more of
those listed above. The ability to connect to multiple back-end systems and system types allows for data
synchronization from disparate systems in a seamless manner for mobile application end users.
You can use Connector Studio, which is part of the Agentry Editor, to configure connectivity to WSDL or SQL
systems. You can use the Agentry SDKs to develop custom code that provides connectivity logic for setting up
back-end connections. For example, you can use the Agentry “steplet” APIs to write SAP back-end interface
code that connects the Agentry application to ABAP. You can make connections to multiple back-end systems
using both custom code and Connector Studio configuration for access via a single application.
13
Sybase® Unwired Platform 2.3 Sizing Guide
SIZING FUNDAMENTALS AND TERMINOLOGY
For the purpose of this guide, we assume that you are familiar with sizing fundamentals. You can find more
information at http://service.sap.com/sizing. > Sizing > Sizing Decision Tree > General Sizing Information.
This section explains important sizing terms that are used extensively in this document.
Sizing
Sizing means determining the hardware requirements of an SAP application, such as the network bandwidth,
physical memory, CPU processing power, and I/O capacity. Hardware and database size is influenced by both
business aspects and technological aspects. You must take into account the number of users using the various
application components and the data load they put on the server.
Benchmarking
Determine sizing information using SAP Standard Application Benchmarks and scalability tests, both are
available from www.sap.com/benchmark. Released for technology partners, benchmarks provide basic sizing
recommendations by placing a substantial load on a system during the testing of new hardware, system software
components, and relational database management systems (RDBMSs). All performance data relevant to the
system, user, and business applications are monitored during a benchmark run and can be used to compare
platforms.
SAP Application Performance Standard
The SAP Application Performance Standard (SAPS) is a hardware-independent unit that describes the
performance of a system configuration in the SAP environment. It is derived from the Sales and Distribution (SD)
Benchmark, where 100 SAPS is defined as the computing power to handle 2,000 fully business processed order
line items per hour. See http://www.sap.com/benchmark .
Initial Sizing
Initial sizing refers to the sizing approach that provides statements about platform-independent requirements of
the hardware resources necessary for representative, standard delivery SAP applications. The initial sizing
guidelines assume optimal system parameter settings, standard business scenarios, and so on.
Expert Sizing
Expert sizing refers to a sizing exercise where customer-specific data is analyzed and used to put more detail on
the sizing result. The main objective is to determine the resource consumption of customized content and
applications (not SAP standard delivery) by comprehensive measurements. See http://service.sap.com/sizing
> Sizing Decision Tree >General Sizing Information > Expert Sizing.
Configuration and System Landscaping
Hardware resource and optimal system configuration greatly depend on the requirements of the customerspecific project. Considerations include the implementation of distribution, security, and high availability solutions
14
Sybase® Unwired Platform 2.3 Sizing Guide
by different approaches using various third-party tools. In the case of high availability through redundant
resources, for example, final resource requirements must be adjusted accordingly.
Some best practices may be valid for a specific combination of operating system and database. To provide
guidance, SAP created the NetWeaver configuration guides, available from http://service.sap.com/instguides
> SAP NetWeaver.
15
Sybase® Unwired Platform 2.3 Sizing Guide
INITIAL SIZING FOR ODATA MESSAGING APPLICATIONS
Assumptions
Portions of the OData SDK, specifically parsing, may be used with REST or messaging. The first section covers
messaging where connections are made through the SDK libraries; REST sizing is covered in a different table.
The ODP service is generally suitable for small payload scenarios. You must remap scenarios that exceed these
characteristics to other more robust transfer protocols.
To properly estimate sizing for ODP, planners should determine the specific application demand on servers.
These factors affect the sizing calculations:

Rate at which requests are executed

Size of the data sent between the server and the device
The combination of these factors reflects the application load on the server, based on the rate of messages.
When comparing your deployment to the business scenarios presented in this paper, adjust your deployment
calculations based on variances in these factors. The number of registered users in the system has a relatively
minor impact on runtime sizing or performance.
Business Scenario
The business example for the OData application is a lookup application for sales orders. The device starts a
pattern of request/response by initiating a lookup on the server for a set of sales orders. The server responds to
this request by sending a collection of sales orders that contains two sales orders.
NOTE: Compression was turned on for the payloads for ODP and REST.
Data Object Structure
The sales order field number and size is not important in the context of the Unwired Server sizing because the
server is acting as a proxy without inspecting or manipulating the payload. The sales order in the reference
scenario returns entities with approximately 30 fields. The payload size in the reference scenario is equivalent to
two sales orders. The total payload size is 16KB, including XML tags and attributes.
Key Considerations for the Sizing Analysis
The request/response metrics for the reference sizing scenario of 16KB messages is listed below. ODP
request/response sizing does not make a distinction between the Unwired Server node and the data tier
because the request/response does not use the database for storing messages.
16
Sybase® Unwired Platform 2.3 Sizing Guide
Messaging Channel Sizing
Sizing
Category
Request /Response
Server SAPS
Memory in GB
per second
Small
500
12,000
8
Medium
750
18,000
12
Large
1,000
24,000
16
Table 1. Reques t/respon se metrics for 1 6 kB messages
The REST-based request/response metrics for the reference sizing scenario of 16kB messages is listed below.
It is recommended that compression be enabled for the REST channel to reduce the network load on the SUP
server at high throughput.
Sizing
Category
Request /Response
Server SAPS
Memory in GB
per second
Small
1,000
8,500
6
Medium
1,500
12,750
8
Large
2,000
17,000
16
Table 2. Request/response metrics for 16kB payloads
Effect of Payload Size on Server Sizing
The size of the payload has a material impact on the sizing of the proxy. See the table below to calculate the
additional Server SAPS that are required to service the payloads above 16K. Lookup the sizing factor in the
table below then multiply the SAPS found in the sizing table above with the sizing factor. The sizing factor table
below can be used for both the messaging channel and the REST channel.
17
Sybase® Unwired Platform 2.3 Sizing Guide
Sizing Factor for Different Payload Sizes
20
18
16
Sizing Factor
14
12
10
8
6
4
2
0
0
200
400
600
800
1000
1200
Payload Size [kB]
If the messaging channel is used with a 16 kB payload, the server SAPS are 12,000 for a throughput of 500
requests/s. If we increase the payload size to 200kB, the sizing factor is 4. For a payload size of 200kB with a
throughput of 200 requests/s, the SAPS are calculated to be 48,000. Alternatively, we can reduce the
throughput by the scaling factor. With a payload size of 200kB and a server with 12,000 SAPS, the throughput is
125 reqests/s.
If an ODP scenario requires notifications, then the sizing below must be applied in addition to the
request/response calculations. The processing cost for notifications is higher than the cost of
requests/responses.
Sizing
Category
Notifications per second
Server SAPS
Memory in GB
Small
50
2,500
4
Medium
100
5,000
8
Large
150
7,500
8
Table 3. O DP notifica tion s
18
Sybase® Unwired Platform 2.3 Sizing Guide
INITIAL SIZING FOR MESSAGING APPLICATIONS
Assumptions
The Hybrid Web Container is suitable for small payload scenarios. You must remap scenarios that exceed these
characteristics to native custom applications.
To properly estimate the sizing for messaging applications, planners should determine the specific application
demand on servers. These factors affect the sizing calculations:

Total user population

Rate at which workflows are executed (number of application requests per hour)

Size of the data sent between the server and the device
The combination of these factors reflects the application load on the server based on the rate of messages.
When comparing your deployment to the business scenarios presented in this paper, adjust your deployment
calculations based on variances in these factors. The number of registered users in the system has a relatively
minor impact on sizing or performance.
Business Scenario
The business example for the messaging application is sales orders approval. A back-end process starts with a
push from the back-end workflow system to SUP via a Workflow Data Change Notification (WF-DCN), which
signals the start of a mobile workflow and is sent through SUP to the specific device/user registered for this
workflow. The device responds by changing the approved field to indicate the status, and an asynchronous
action is passed on to the back end; the workflow implicitly terminates. The total number of messages for this
messaging scenario is two per complete workflow—initialization and response/termination.
NOTE: Compression was turned on for the payloads.
Data Object Structure
To trigger the mobile workflow in this scenario, a message is sent from the back-end to Unwired Server via WFDCN where it triggers a query to populate the online cache with data from the backend based on the USERID
and ORDERID parameters. The server then constructs the workflow order-approval request message from the
online data and routes the request to the device. The single-dimensional object used in the message in this case
is a simple approval object without any further references. The payload size in this scenario is 64kB per workflow
message and the MBO is pictured here.
19
Sybase® Unwired Platform 2.3 Sizing Guide
Figure 5. W orkflow data model
Key Considerations for the Sizing Analysis
Within any workflow at least two messages are involved, one from the back-end and a response from the device.
Extra online invocations to the mobile middleware may occur during the workflow but are not accounted for in
this sizing. Larger payloads increase the time to move and marshal data throughout the system; Sybase
recommends small payloads for workflow applications.
Workflow Reference Sizing reflects a push from the back-end and a response from the device to an MBO in an
online cache group so the response does not go through the MBO cache.
20
Sybase® Unwired Platform 2.3 Sizing Guide
Workflow reference sizing uses a push action from the back-end and a response from the device for an MBO in
an online cache group, so neither the request nor the response go through the persistent cache. Remember to
account for any extra online interactions from the device within the context of the workflow.
Sizing
Category
Workflows per
Server SAPS
Memory in GB
Data Tier SAPS
hour
Data Tier
Memory in GB
Small
20,000
5,000
4
1,100
4
Medium
40,000
10,000
7
2,200
4
Large
60,000
15,000
10
3,300
7
Table 4. W orkflow referenc e sizing
21
Sybase® Unwired Platform 2.3 Sizing Guide
INITIAL SIZING FOR SYNCHRONIZATION APPLICATIONS
Assumptions
Business Scenario
This business scenario and data model for both SUP Cache and SUP-DOE is the same. However, the sizing
and performance characteristics for these two technologies are different. In arriving at the sizing guidelines, we
used a Service Order Management application as the example. This application is intended for service personnel
in the field.
This scenario includes customers placing service-order requests in the back office of a service company. The
requests are stored in a back-end system, along with information like the customer’s address, contact
information, details of the product that have to be serviced, and so on. After a request has been placed, the field
personnel assigned to the region where the customer is located, receives the order request. The mobile
application allows the field personnel to make changes to the order and send to the backend system via the
mobile middleware.
In one case the mobile user has connectivity during working hours and orders are sent and received by the
device during working hours. We refer to this case as being online. In the online case the middleware system is
fairly evenly loaded during the day. In this scenario the mobile device is mostly connected to the SUP server
during business hours.
In another use case, the user only synchronizes in the evening, say at 7 pm. On synchronization, the mobile
client uploads all the requests, which have been processed during the day, to the backend. The next
synchronization of the user occurs the following morning, at 7 am. The data is transferred to the device in a
single synchronization operation.
Then the middleware processes the uploaded data, transmitting it to the backend. In this second scenario, the
mobile device is mostly not connected to the SUP server during business hours.
NOTE: Compression of the synchronization payload is not enabled.
22
Sybase® Unwired Platform 2.3 Sizing Guide
Data Object Structure
For all sizing measurements, orders records are either downloaded or uploaded from the device. The table
below depicts order data sizes for the business scenario.
Online
Object
# Per Order
Offline
Size (B)
# Per Order
Size (B)
Order
1
901
1
901
Order Component
2
274
12
6850
Order Activity
3
381
17
13335
Order Object list
5
455
25
22750
Total (including
4867
43836
header)
Table 5. S ynch ronization data ob jec t cardinalit y
Figure 11. S yn chronization refer ence model
Key Considerations for the Sizing Analysis
The sizing for synchronization is considered in two operational scenarios, offline and online. In the offline case all
transfers for a working day are accomplished at one time — at the start of the working day (download) and at the
end of the working day (upload).
The offline operations are referred to as synchronizations and sized in terms of downloads and uploads per hour.
Each synchronization contains multiple order changes. A single upload or download synchronization is
23
Sybase® Unwired Platform 2.3 Sizing Guide
comprised of the data operations for the working day (order deletes, inserts, and modifications) as described in
the table below.
Offline Phase
Affected Order
Insert Orders
Delete Orders
Modified Orders
2066 Kb (~2MB)
32
32
32
1033 Kb (~1MB)
N/A
N/A
48
Data Size
Download
Synchronization
Upload
Synchronization
Table 6. Per de vice orde r c hanges per s yn chronizatio n for offline scenarios
In the online scenario, data is transferred throughout the working day and therefore the amount of data
transferred at any one interaction with the server is proportionally smaller (daily amount/number of server
interactions). Unlike the offline guidance, the online scenario throughput is communicated in terms of order
operations per hour where twice as many modifications were downloaded as were uploaded.
SUP Cache Sizing Guidance
The guidance in this section is based on the same business case, data model, and data cardinality as the DOE
synchronization scenario but uses only the SUP cache middleware between the backend system and the device.
As of SUP version 2.1 ESD #2, upload and download cache synchronization are decoupled (asynchronous
upload). Decoupling upload and download decreases lock contention and provides far better data tier CPU
utilization. Lower CPU utilization allows for greater throughput on similar hardware.
Older SUP device applications running on a newer server, or applications that switch to the non-default
synchronous upload, will not take advantage of the asynchronous upload feature resulting in data tier CPU
utilization approximately twice as high as the guidance in this document.
Online
This online sizing is based on a constant throughput of orders during the day. Orders are downloaded and
uploaded concurrently with the rates shown below.
SUP
Category
SAPS
Memory in
SUP Data Tier
Upload
Download
SAPS
Orders/HR
Orders/HR
Small
8,000
16,000
2,800
6
2,400
4
Medium
12,000
24,000
4,300
8
3,600
6
Large
16,000
32,000
5,800
12
4,800
8
GB
Memory in
GB
Table 7. SUP ca che online as ynchronou s mode
24
Sybase® Unwired Platform 2.3 Sizing Guide
Offline Download
During the nightly back office processing window order inserts, deletes, and updates are issued from the
backend directly to the SUP cache in the form of Data Change Notifications (DCN).
Because the offline scenario calls for DCN (night), delta download (morning), and delta upload (evening) to
occur at mutually exclusive periods of time, use the greater of the sizing requirements for deployment. The DCN
metrics depict the total DCN activity to upload the entire daily payload to a device.
Category
DCN Activity
Client
Sizing
Server SAPS
Payloads Per
Memory in
Data Tier SAPS
GB*
Data Tier
Memory
Hour
Small
1,000
11,000
10
13,000
7
Medium
1,500
16,500
14
19,500
11
Large
2,000
22,000
20
26,000
14
Table 8. SUP ca che offline DCN
*Memory per SUP server node.
25
Sybase® Unwired Platform 2.3 Sizing Guide
In the offline scenario device users synchronize the back office DCN change to the device when they come
online before they start their workday. During this synchronization users are downloading multiple order changes
(inserts, deletes, and modifications).
Category
Download
Synchronizations
Sizing
Server SAPS
Per Hour
Memory in
Data Tier SAPS
GB*
Data Tier
Memory
Small
9,000
4,000
6
10,000
6
Medium
18,000
8,000
12
20,000
12
Large
27,000
12,000
18
30,000
18
Table 9. SUP ca che offline dow nload
*Memory per SUP server node.
Offline Upload
At the end of the business day offline device users synchronize (upload) their daily changes to SUP and they are
committed to the backend asynchronously from the upload.
Category
Upload
Synchronizations
Sizing
Server SAPS
Per Hour
Memory in
Data Tier SAPS
GB*
Data Tier
Memory
Small
8,000
4,600
5
5,600
4
Medium
16,000
9,200
10
11,200
8
Large
24,000
13,800
15
33,600
12
Table 1 0. SUP cache offline upload
*Memory per SUP server node.
26
Sybase® Unwired Platform 2.3 Sizing Guide
SUP-DOE Sizing Guidance
Online
This sizing is based on a constant throughput of orders during the test. Orders are downloaded and uploaded
concurrently with the rates shown below.
SAP NetWeaver
SUP
SUP Data Tier
Application Server
and Database
Category
Upload
Download
SAPS
Memory
Orders/Hr
Orders/Hr
ABAP
in GB
SAPS
Memory
SAPS
in GB
Memory
in GB
Server
Small
8,000
16,000
5,200
12
1,200
4
800
4
Medium
12,000
24,000
7,800
16
1,800
4
1,200
4
Large
16,000
32,000
10,400
24
2,400
4
1,600
4
Table 1 1. SUP-DOE online sizing
Offline Download
During the nightly back office processing window order inserts, deletes, and updates are batched from the
backend to DOE and SUP. The computation is performed on the DOE system, so only DOE sizing is shown.
Since this activity is performed at a mutually exclusive time to device upload and download, the DOE sizing for
this phase is not additive to other phases — take the higher of the DOE offline download processing or
synchronization cases.
SAP NetWeaver Applications Server and Database
Category
Synchronizations / Hr
SAPS ABAP Server
Memory in GB
Small
350
4,300
12
Medium
700
8,600
16
Large
1,050
13,000
24
Table 1 2. Offline dow nload DOE processing
The messages are delivered from DOE to SUP messaging nodes in preparation for device download. When the
devices come online during the morning period, the devices download their data from SUP. Only the SUP sizing
is relevant in this phase.
27
Sybase® Unwired Platform 2.3 Sizing Guide
Category
Synchronizations
/ Hr
SUP
SAPS SUP
SUP Data Tier
Memory in GB
SAPS
Memory in GB
Server
Small
6,500
3,000
4
1,100
4
Medium
13,000
6,000
8
2,200
8
Large
19,500
9,000
8
3,300
8
Table 1 3. SUP offline dow nload for DOE
Offline Upload
In our scenario, the afternoon operation is the upload operation. The devices can either upload their data to SUP
and go offline immediately, or wait for a confirmation from DOE and the back office system that uploads were
processed successfully. The throughput for the SUP upload operation is relatively fast compared to waiting for a
confirmation.
Category
Synchronizations
/ Hr
SUP
SAPS SUP
SUP Data Tier
Memory in GB
SAPS
Memory in GB
Server
Small
4,000
2,200
4
3,000
4
Medium
8,000
4,400
4
6,000
4
Large
12,000
6,600
8
9,000
8
Table 1 4. SUP offline upload for DOE
28
Sybase® Unwired Platform 2.3 Sizing Guide
INITIAL SIZING FOR AGENTRY APPLICATIONS
Assumptions
The primary artifacts for Agentry synchronization are data tables, complex tables, and objects. Data tables and
complex tables are intended to be used for read-only tables on the device. These tables can be large, and
synchronization is relatively efficient because individual element keys are generally not sent to the server for
processing. Objects are designed for transactional updates, so all associated keys are normally sent to the
server as part of the synchronization fetch (download) processing. These differences in typical processing
behavior may affect the sizing calculation.
When a device initiates a synchronization operation, client operations (transactions) are executed first. These
transactions include device-initiated update, delete, and insert operations. The device sends transaction data for
objects to the Agentry Server for processing.
Next, a fetch operation is started. The device sends all object primary keys and last-changed timestamps to the
Agentry Server. The server-defined fetch steps are executed.
Fetch operations are defined as a series of steps. Each fetch operation may include:
o Client exchange steps
o Server exchange steps
o Removal steps
You may choose to design an application to execute a step once per object during synchronization; however,
SAP recommends that you do not use this type of step definition, due to much higher server resource
requirements. This type of interaction is not covered in this sizing guide.
Normally, the keys and last update time on each device are tracked using a client exchange table, which is
updated by the client exchange steps. Server exchange steps fetch the objects that have changed or that do not
exist on the device. Finally, removal steps retrieve the objects that should be deleted from the device.
Data Object Structure
For all sizing measurements, order records are either downloaded or uploaded from the device. Each order row
has a data size of 901bytes. The schema is illustrated below.
29
Sybase® Unwired Platform 2.3 Sizing Guide
Figure 12. Order Header O bjec t
The sizing is based on tests that use a RDBMS (SQL) back end.
Agentry Sizing Guidance
To size an Agentry system, consider these dimensions:
o Base SAPS – the overhead to perform a synch depends on the number of keys sent to the server (only
for object instances, not data tables or complex tables).
o Download SAPS – the resources required to download rows to a device (for example, EIS updates).
o Upload SAPS – the additional resources required to upload rows to the EIS (for example, device insert
transactions).
When device databases contain many objects, the key transmission overhead becomes significant. You can
ignore this sizing dimension if the amount of object data on the device is small. Weigh the significance and
30
Sybase® Unwired Platform 2.3 Sizing Guide
impact of each of the three dimensions, then add the respective recommendations to determine the overall
sizing for the system.
The sizing guidance does not include the resources required for the back-end system. The Agentry Server
requires minimal disk I/O resources. Memory use depends on the number of applications that are deployed.
Base Calculation (Object Key Transmission Overhead)
Determine the peak number of users who will interact with the server during any one-hour period. Use the
appropriate base SAPS from table 15.
Category
Synchronizations /
Base SAPS SMP Server
second
Small
10
1100
Medium
20
2200
Large
40
4400
Extra Large
80
8800
Table 1 5 – Agen tr y Bas e SAP S
Next, use Table 16 to look up the sizing multiplier. Multiply the base SAPS by the sizing multiplier.
Number of Instances in
Base SAPS Multiplier
Each Device Database
2500
7.5
5000
13
10,000
26
20,000
52
Table 1 6 – Agen tr y Bas e SAP S M ultiplier
This calculation is significant if the number of object instances on the device is large, and if the number of
synchronizations is frequent; otherwise, you can ignore it.
31
Sybase® Unwired Platform 2.3 Sizing Guide
Fetch (Download) Calculation
The download data SAPS is determined by the number of rows transmitted through the Agentry Server to
devices.
Category
Rows / second
SAPS SMP Server
Small
1000
1100
Medium
2000
2200
Large
4000
4400
Extra Large
8000
8800
Table 1 7 – Agen tr y Dow nload S APS
Upload Calculation
The amount of uploaded data is dependent on the number of transactions (insert, update, delete) performed on
the device. This sizing is dependent on both the application and the business process of the end user.
Category
Rows / second
SAPS SMP Server
Small
100
1350
Medium
200
2700
Large
400
5400
Extra Large
800
10800
Table 1 8 – Agen tr y Upload S APS
32
Sybase® Unwired Platform 2.3 Sizing Guide
Example
During the highest workload period of the day, there are 5000 active users. During this peak period, the 5000
users synchronize 15 times per hour. Each user has 1000 rows in the device database. On average, each user
downloads 50 records and uploads 5 records during each synch.
1. Calculate the base SAPS:
There are 15 synchs per hour per user with 5000 users = 75,000 synchs /hr or 21 sync/s. The device
database has 1000 rows, so the base sizing constant is 3. The total base SAPS is 2,200 * 3 = 6,600
SAPS.
2. Calculate the download SAPS:
The download data volume is 21 syncs/s * 50 rows/sync = 1,050 rows/s. The download SAPS are 1,100.
3. Calculate the upload SAPS:
The upload data volume is 21 sync/s * 5 rows/sync = 105 rows/s. The upload SAPS are 1,350.
Total SAPS are (6,600 + 1,100 + 1,350) = 9,050.
33
Sybase® Unwired Platform 2.3 Sizing Guide
APPENDIX
Physical I/O Subsystems
Synchronization and workflow applications are heavily reliant on one or more forms of persistence in the middle
tier, implying that the scalability of the server is a direct reflection of the properties of the physical storage
infrastructure. Systems prior to SUP 2.3 used two storage subsystems and those starting with SUP 2.3 use a
single database type to reduce the cost of maintenance and recovery. To increase the throughput on the storage
subsystems, separate physical I/O contenders and their associate logs onto separate disk spindles or RAID
systems. Fast storage (that is, SSD or a tiered SAN) is essential for obtaining high throughput in systems that
rely on the database.
Network Latency
All the sizing reference numbers are for LAN-based device communication. 3G or Wi-Fi networks have different
response times and should be taken into account when considering individual download speeds. Applicationspecific testing is required to adequately test performance.
34
www.sap.com
© 2013 SAP AG. All rights reserved.
SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP
BusinessObjects Explorer, StreamWork, SAP HANA, and other SAP
products and services mentioned herein as well as their respective
logos are trademarks or registered trademarks of SAP AG in Germany
and other countries.
Business Objects and the Business Objects logo, BusinessObjects,
Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and
other Business Objects products and services mentioned herein as
well as their respective logos are trademarks or registered trademarks
of Business Objects Software Ltd. Business Objects is an SAP
company.
Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL
Anywhere, and other Sybase products and services mentioned herein
as well as their respective logos are trademarks or registered
trademarks of Sybase Inc. Sybase is an SAP company.
Crossgate, m@gic EDDY, B2B 360°, and B2B 360° Services are
registered trademarks of Crossgate AG in Germany and other
countries. Crossgate is an SAP company.
All other product and service names mentioned are the trademarks of
their respective companies. Data contained in this document serves
informational purposes only. National product specifications may vary.
These materials are subject to change without notice. These materials
are provided by SAP AG and its affiliated companies ("SAP Group")
for informational purposes only, without representation or warranty of
any kind, and SAP Group shall not be liable for errors or omissions
with respect to the materials. The only warranties for SAP Group
products and services are those that are set forth in the express
warranty statements accompanying such products and services, if
any. Nothing herein should be construed as constituting an additional
warranty.
.