Citrix

Produktdokumentation



Ganzes Dokument herunterladen

Tuning XenMobile Operations

Jan. 12, 2017

The performance and stability of XenMobile operations involves many settings across XenMobile and depends on your NetScaler and SQL Server database configuration. This article focuses on the settings that are most often configure, related to the tuning and optimization of XenMobile. Citrix recommends that you evaluate each of the settings in this article before deploying XenMobile.

Important

These guidelines assume that the XenMobile server CPU and RAM is adequate for the number of devices. For more information about scalability, see Scalability and performance in the XenMobile documentation.

The following server properties globally apply to operations, users, and devices across an entire XenMobile instance. Be aware that a change to some server properties requires a restart of each XenMobile server node. XenMobile notifies you when a restart is required.

These tuning guidelines apply to both clustered and non-clustered environments.

Settings

Up to 5,000 devices

5,000 to 15,000 devices

More than 15,000 devices

hibernate.c3p0.max_size

This XenMobile server property, Custom Key, determines the maximum number of connections that XenMobile can open to the SQL Server database. XenMobile uses the value you specify for this custom key as an upper limit; the connections open only if you need them. Base your settings on the capacity of your database server. Default is 200.

To change this setting, you must add a server property to XenMobile server with the following configuration:

Key: Custom Key

Key: hibernate.c3p0.max_size

Value: 500

Display name: hibernate.c3p0.max_size=nnn

Description: DB connections to SQL

Setting the value too high with an undersized SQL Server can cause resource issues on the SQL side during peak load. Setting the value too low means you might not be able to take advantage of the SQL resources available.

200

500

1000

Note: In high load situations, such as a very large deployment, consider setting this key to 1000 to better handle the extra load when a large number of devices connect simultaneously.

hibernate.c3p0.timeout

This XenMobile server property, Custom Key, determines the idle time-out. Default is 300.

Key: Custom Key

Key: hibernate.c3p0.timeout

Value: 30

Display name: hibernate.c3p0.timeout=30

Description: Database idle timeout

If you use database cluster failover, Citrix recommends that you add this Custom Key and set it to reduce the idle time-out to about 30 seconds.

Push Services Heartbeat Interval

This setting determines how frequently an iOS device checks if an APNs notification is not delivered in the interim. Increasing the APNs heartbeat frequency can optimize database communications. Too large a value can add unnecessary load. This setting applies only to iOS. Default is 6 hours.

If you have a large number of iOS devices in your environment, the heartbeat interval can lead to higher load than necessary. Security actions, such as selective wipe, lock, full wipe, and so on do not rely on this heartbeat, as an APNs notification is sent to the device when these actions are executed. This value governs how quickly a policy updates after Active Directory Group membership changes. As such, it is often suitable to increase this value to something between 12 and 23 hours to reduce load.

23 hours

23 hours

7 days

iOS MDM APNS Connection Pool Size

An APNs connection pool that is too small can negatively affect APNs activity performance when you have more than 100 devices. Performance issues include slower deployment of apps and policies to devices and slower device registration. Default is blank, meaning 1.

Recommended setting is 10 or up to the maximum number of APNs servers for your geographic location.

Other Server Optimizations

Server Property

Default Setting

Why Change This Setting?

Interval for check deleted Active Directory user

 0 minutes

The default value 0 prevents XenMobile from checking for deleted Active Directory users. Increase this value to match your Active Directory sync setting. The standard sync time for Active Directory is 15 minutes.

Background Deployment

360 minutes

The frequency for background policy deployments, in minutes. Applies only to always-on connections for Android devices. Increasing the frequency of policy deployments reduces server load. Recommended setting is 1440 (24 hours).

Background Hardware Inventory

360 minutes

The frequency for background hardware inventory, in minutes. Applies only to always-on connections for Android devices. Increasing the frequency of hardware inventory reduces server load. Recommended setting is 1440 (24 hours).

Custom keys:
auth.ldap.connect.timeout=60000

auth.ldap.read.timeout=60000

 6000

To compensate for slow LDAP responses, Citrix recommends that you add server properties for the following Custom Keys.

Key: Custom Key
Key: auth.ldap.connect.timeout
Value: 60000
Display name: auth.ldap.connect.timeout=60000
Description: LDAP connection timeout

Key: Custom Key
Key: auth.ldap.read.timeout
Value: 60000
Display name: auth.ldap.read.timeout=60000
Description: LDAP read timeout

Optimizing Deployment Scheduling for Android Devices

You can schedule deployments for Android devices using the Google Firebase Cloud Messaging (FCM, previously named Google Cloud Messaging) or XenMobile settings.

If using FCM to schedule deployments

Enabling FCM for your XenMobile environment allows for near real-time notifications to Android devices, similar to APNs for iOS devices. With FCM configured, when XenMobile needs to connect to a device for a policy update, selective wipe, and so on, the XenMobile server sends a notification message to the FCM server to forward the request to the client device. After the device receives the notification from FCM, the device connects back to XenMobile for further instructions. Keep in mind that this method relies on third-party servers (Google) and therefore is subject to service interruptions outside the control of your IT department or Citrix Support.

For information on how to register with the FCM service, refer to XenMobile and Firebase Cloud Messaging (FCM) Configuration.

If using FCM for Android, be aware of the following XenMobile server properties. The properties still use the prior acronym for Google Cloud Messaging, GCM.

  • GCM API Key: The key created in the Google Developers Console.
  • GCM Sender ID: The Project Number in the Google Developers Console.
  • GCM Registration ID TTL: The delay, in days, before renewing the device FCM registration ID. Defaults to 10.
  • GCM Heartbeat Interval: Defaults to 6 hours.

If using XenMobile settings to schedule deployments

To schedule deployments to Android devices, use these XenMobile settings:

  • Set the Connection Scheduling Policy (a XenMobile device policy) to Always, which keeps the connection alive permanently. This enables you to deploy policies to delivery groups immediately. The open connection also enables the background services defined in the server properties Background Deployment and Background Hardware Inventory to occur per those property settings.
  • Select the Deployment Schedule option Deploy for always-on connection in each policy deployed to the device.

Note

For Android devices, setting the Deployment condition to Only when previous deployment has failed helps with device usage, because some devices overwrite the policy and some devices reset the policy. If a device resets the policy, XenMobile might prompt users for credentials every time a policy that requires authentication is re-deployed. Enabling this feature also helps with server load and prevents the success reported from bouncing between failed and success when XenMobile pushes the policy every time the device connects.

Back to Top