Test Methodology

Test Methodology

The tests were run against XenMobile Enterprise to establish benchmarks. In an effort to target both small and large scale deployments, 1,000 to 10,0000 devices were used in the measurements.

Workloads were created to simulate real-world use cases. These workloads were run for each test to study the effect on enrollment and logon rates. The objective of the tests was to obtain an optimal logon rate that was within the acceptable margin of error as outlined in . Logon rates are a critical factor in determining the hardware configuration recommendations for the infrastructure components.

The On-boarding (FTU) workload logon requests included auto discovery, authentication, and device registration operations. Application subscription, installation, and launch operations were uniformly distributed throughout the test period. This provided the best real-world simulation of user actions. At the conclusion of the test, the session was logged out. The Existing User workload logon requests included only authentication requests.

Workloads

On-Boarding (FTU) Workload

The On-boarding (FTU) workload is defined as the first time a user accesses the XenMobile environment. Operations included in this workload were:

Auto discovery

Enrollment

Authentication

Device registration

Application delivery (web, SaaS, and mobile MDX apps)

App subscription (including images and icon downloads)

Installation of the subscribed MDX apps

App launch (web, SaaS, and mobile MDX apps)

Minimal WorxMail and WorxWeb connections (VPN tunnels) — two connections

Installation of required apps through XenMobile

The workload parameters included:

1 device registration per device

1 enumeration per device

14 apps enumerated per device

4 Worx Store launches per device

4 web/SaaS app SSOs per device

1 MDX app downloaded per device

2 required app downloads

Existing Users Workload

The following table shows the Existing Users workload. This workload simulated a user using WorxMail and WorxWeb apps. This simulation was used to measure the NetScaler Gateway port's scalability within the XenMobile configuration. For the WorxWeb app, users were accessing internal web sites, which do not trigger XenMobile SSO. Operations in this mode included:

Authentication (NetScaler Gateway and XenMobile)

WorxMail and WorxWeb connections (VPN tunnels) — four connections

WorxApps Connection Profiles

1. Per session: 8 hours.

2. Type 1: Asymmetric send and receive with long lived connections (that is, WorxMail with a dedicated Microsoft Exchange mailbox connection).

3. Type 2: Asymmetric send and receive with connections that close and reopen after delays (that is, WorxWeb connections).

Note: Modifications to the connection details affect analysis results. For example, if the number of connections per user is increased, then the number of NetScaler Gateway sessions supported may be reduced.

WorxMail and WorxWeb Profiles

The following tables show the WorxMail and WorxWeb profile details.

Table 5. WorxMail Profile for a Medium Workload

Messages sent per day 20

Messages received per day 80

Messages read per day 80

Messages deleted per day 20

Average message size (KB) 200

Table 6. WorxWeb Profile for Medium Workload

Number of web apps launched 10

Number of web pages opened manually 10

Average number of request–response pairs per web app 100

Average size of request (bytes) 300

Average size of response (bytes) 1000

Configuration and Parameters

The following configurations were used when running the scalability tests:

NetScaler Gateway and load balancing (LB) virtual servers coexisted on the same NetScaler Gateway

appliance.

A 2048-bit key was used on NetScaler Gateway for SSL transactions.