Product Documentation

Optimisation des opérations XenMobile

Les performances et la stabilité des opérations XenMobile impliquent de nombreux paramètres sur XenMobile et dépendent de votre configuration de base de données NetScaler et SQL Server. Cet article se concentre sur les paramètres liés à l’optimisation de XenMobile les plus souvent configurés par les administrateurs. Citrix vous recommande d’évaluer chacun des paramètres de cet article avant de déployer XenMobile.

Important :

Ces instructions supposent que l’UC et la RAM de XenMobile Server sont adaptés au nombre d’appareils. Pour plus d’informations sur la montée en charge, consultez la section Capacité à monter en charge et performances.

Les propriétés de serveur suivantes s’appliquent globalement aux opérations, utilisateurs et appareils sur une instance XenMobile entière. La modification de certaines propriétés de serveur nécessite un redémarrage de chaque nœud de serveur XenMobile. XenMobile vous informe lorsqu’un redémarrage est requis.

Ces instructions d’optimisation s’appliquent à la fois aux environnements en cluster et sans cluster.

hibernate.c3p0.idle_test_period

Cette propriété de serveur XenMobile, une clé personnalisée, détermine le temps d’inactivité en secondes avant qu’une connexion soit automatiquement validée. Configurez la clé comme suit. La valeur par défaut est 30.

  • Clé : Clé personnalisée
  • Clé : hibernate.c3p0. idle_test_period
  • Valeur : 30
  • Nom d’affichage : hibernate.c3p0. idle_test_period
  • Description : Période d’inactivité prolongée de test

Hibernate.C3P0.max_size

Cette clé personnalisée détermine le nombre maximal de connexions que XenMobile peut ouvrir pour la base de données SQL Server. XenMobile utilise la valeur que vous spécifiez pour cette clé personnalisée en tant qu’une limite supérieure. Les connexions s’ouvrent uniquement si vous en avez besoin. Basez vos paramètres sur la capacité de votre serveur de base de données.

Notez l’équation suivante dans une configuration en cluster. Votre connexion c3p0 multipliée par le nombre de nœuds est égale au nombre maximum de connexions que XenMobile peut ouvrir à la base de données SQL Server.

Dans une configuration en cluster et sans cluster, la définition d’une valeur trop élevée avec un serveur SQL Server sous-dimensionné peut entraîner des problèmes de ressources côté SQL pendant la charge de pointe. Si vous définissez une valeur trop faible, vous ne pourrez peut-être pas tirer parti des ressources SQL disponibles.

Configurez la clé comme suit. La valeur par défaut est 1000.

  • Clé : hibernate.c3p0.max_size
  • Valeur : 1000
  • Nom d’affichage : hibernate.c3p0.max_size
  • Description : Connexions de base de données à SQL

hibernate.c3p0.min_size

Cette clé personnalisée détermine le nombre minimal de connexions que XenMobile ouvre pour la base de données SQL Server. Configurez la clé comme suit. La valeur par défaut est 100.

  • Clé : hibernate.c3p0.min_size
  • Valeur : 100
  • Nom d’affichage : hibernate.c3p0.min_size
  • Description : Connexions de base de données à SQL

hibernate.c3p0.timeout

Cette clé personnalisée détermine le délai d’inactivité. Si vous utilisez le basculement de cluster de base de données, Citrix vous recommande d’ajouter cette clé personnalisée et de la définir pour réduire le délai d’inactivité. La valeur par défaut est 120.

  • Clé : Clé personnalisée
  • Clé : hibernate.c3p0.timeout
  • Valeur : 120
  • Nom d’affichage : hibernate.c3p0.timeout
  • Description: Délai d’inactivité de la base de données

Intervalle de pulsation des services Push

Ce paramètre détermine la fréquence à laquelle un appareil iOS vérifie si une notification APNs n’est pas fournie entre temps. L’augmentation de la fréquence de pulsation APNs peut optimiser les communications de la base de données. Une valeur trop grande peut ajouter une charge inutile. Ce paramètre s’applique uniquement aux appareils iOS. La valeur par défaut est de 20 heures.

Si vous avez un grand nombre d’appareils iOS dans votre environnement, l’intervalle de pulsation peut entraîner une charge plus importante que nécessaire. Les actions de sécurité, telles que l’effacement sélectif, le verrouillage ou l’effacement complet, ne reposent pas sur cette pulsation, une notification APNs étant envoyée à l’appareil lorsque les actions sont exécutées. Cette valeur détermine la rapidité de mise à jour d’une stratégie après la modification de l’appartenance au groupe Active Directory. Par conséquent, il est souvent approprié d’augmenter cette valeur entre 12 et 20 heures pour réduire la charge.

Taille du pool de connexions APNS iOS MDM

Un pool de connexions APNs trop petit peut affecter négativement les performances de l’activité APNs lorsque vous avez plus de 100 appareils. Les problèmes de performances incluent un déploiement plus lent des applications et des stratégies sur les appareils et un ralentissement de l’enregistrement des appareils. Le paramètre recommandé est 10 ou le nombre maximal de serveurs APNs pour votre emplacement géographique. La valeur par défaut est 10.

auth.ldap.connect.timeout

Pour compenser les réponses LDAP lentes, Citrix recommande d’ajouter des propriétés de serveur pour la clé personnalisée suivante.

  • Clé : Clé personnalisée
  • Clé : auth.ldap.connect.timeout
  • Valeur : 60000
  • Nom d’affichage : auth.ldap.connect.timeout
  • Description : Délai d’expiration de la connexion LDAP

auth.ldap.read.timeout

Pour compenser les réponses LDAP lentes, Citrix recommande d’ajouter des propriétés de serveur pour la clé personnalisée suivante.

  • Clé : Clé personnalisée
  • Clé : auth.ldap.read.timeout
  • Valeur: 60000
  • Nom d’affichage : auth.ldap.read.timeout
  • Description : Délai d’expiration de la lecture LDAP

Autres optimisations de serveur

     
Propriété du serveur Valeur par défaut Pourquoi modifier ce paramètre ?
Déploiement en arrière-plan 1 440 minutes Fréquence des déploiements de stratégie en arrière-plan, en minutes. S’applique uniquement aux connexions permanentes pour les appareils Android. L’augmentation de la fréquence des déploiements de stratégies réduit la charge du serveur. Le paramètre recommandé est 1440 (24 heures).
Inventaire matériel en arrière-plan 1,440 minutes Fréquence de l’inventaire matériel en arrière-plan, en minutes. S’applique uniquement aux connexions permanentes pour les appareils Android. L’augmentation de la fréquence d’inventaire matériel réduit la charge du serveur. Le paramètre recommandé est 1440 (24 heures).
Intervalle pour vérifier l’utilisateur Active Directory supprimé. 15 minutes L’heure de synchronisation standard pour Active Directory est 15 minutes. La valeur 0 empêche XenMobile de rechercher les utilisateurs Active Directory supprimés. Le paramètre recommandé est 15 minutes.
MaxNumberOfWorker 3 Nombre de threads utilisé lors de l’importation d’un grand nombre de licences VPP. La valeur par défaut est 3. Si vous avez besoin d’une plus grande optimisation, vous pouvez augmenter le nombre de threads. Toutefois, notez qu’avec un nombre important de threads, tels que 6, une importation VPP entraîne une utilisation d’UC élevée.

Optimisation de la planification du déploiement pour les appareils Android

Vous pouvez planifier des déploiements pour les appareils Android à l’aide des paramètres Google Firebase Cloud Messaging (FCM, précédemment appelé Google Cloud Messaging).

L’activation de FCM pour votre environnement XenMobile permet des notifications en temps quasi réel sur les appareils Android, similaires aux APNs pour les appareils iOS. Lorsque FCM est configuré et que XenMobile doit se connecter à un appareil pour une opération telle qu’une mise à jour de stratégie ou un effacement sélectif, le serveur XenMobile envoie un message de notification au serveur FCM pour transférer la demande à l’appareil client. Une fois que l’appareil a reçu la notification de FCM, l’appareil se connecte à XenMobile pour obtenir des instructions supplémentaires. Gardez à l’esprit que cette méthode repose sur des serveurs tiers (Google) et qu’elle est donc soumise à des interruptions de service hors du contrôle de votre département informatique ou du support Citrix.

Pour plus d’informations sur l’enregistrement au service FCM, reportez-vous à la section Configuration de XenMobile et Firebase Cloud Messaging (FCM).

Si vous utilisez FCM pour Android, tenez compte des propriétés du serveur XenMobile suivantes. Les propriétés utilisent toujours l’acronyme antérieur de Google Cloud Messaging, GCM.

  • Clé API de GCM : clé de l’API GCM créée dans Google Developers Console.
  • ID de l’expéditeur de GCM : numéro de projet dans Google Developers Console.
  • Durée de vie de l’ID d’enregistrement de GCM : délai, en jours, avant le renouvellement de l’ID d’enregistrement FCM de l’appareil. La valeur par défaut est 10.
  • Intervalle de pulsation de GCM : la valeur par défaut est 6 heures.

Vérification des blocages dans une base de données SQL et suppression des données historiques

Lorsque vous rencontrez des blocages, exécutez la requête suivante pour les afficher. Un administrateur de base de données ou l’équipe Microsoft SQL pourra ensuite confirmer les informations.

Requête SQL

SELECT

db.name DB_Service,

tl.request_session_id,

wt.blocking_session_id,

OBJECT_NAME(p.OBJECT_ID) BlockedObjectName,

tl.resource_type,

h1.TEXT AS RequestingText,

h2.TEXT AS BlockingTest,

tl.request_mode

FROM sys.dm_tran_locks AS tl

INNER JOIN sys.databases db ON db.database_id = tl.resource_database_id

INNER JOIN sys.dm_os_waiting_tasks AS wt ON tl.lock_owner_address = wt.resource_address

INNER JOIN sys.partitions AS p ON p.hobt_id = tl.resource_associated_entity_id

INNER JOIN sys.dm_exec_connections ec1 ON ec1.session_id = tl.request_session_id

INNER JOIN sys.dm_exec_connections ec2 ON ec2.session_id = wt.blocking_session_id

CROSS APPLY sys.dm_exec_sql_text(ec1.most_recent_sql_handle) AS h1

CROSS APPLY sys.dm_exec_sql_text(ec2.most_recent_sql_handle) AS h2

GO

Nettoyage de la base de données

Important :

Sauvegardez votre base de données avant d’apporter des modifications aux tables.

  1. Exécutez la requête suivante pour vérifier les données historiques.

    select COUNT(\*) as total_record from dbo.EWDEPLOY_HISTO;
    select COUNT(\*) as total_record from dbo.EWSESS;
    select COUNT(*) as total_record from dbo.EWAUDIT;
    
  2. Supprimez les données des trois tables précédentes.

    Remarque :

    Vous pouvez ne pas voir les données historiques dans une table. Si c’est le cas, passez l’exécution de la requête de troncature pour la table en question.

    truncate TABLE dbo.EWDEPLOY_HISTO;
    truncate TABLE dbo.EWSESS;
    truncate TABLE dbo.EWAUDIT;
    
  3. Débloquez les requêtes SELECT qui ont été bloquées en raison des blocages. Cette étape prend en charge les autres blocages.

    ALTER DATABASE <database_name> SET       READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE
    
  4. Par défaut, le nettoyage de la base de données est de sept jours pour la conservation de la rétention de la session et les données de rétention d’audit, ce qui est élevé pour un grand nombre d’utilisateurs. Modifiez la valeur de nettoyage à 1 ou 2 jours. Dans les propriétés du serveur, effectuez les modifications suivantes :

    zdm.dbcleanup.sessionRetentionTimeInDays = 1 day
    zdm.dbcleanup.deployHistRetentionTimeInDays = 1 day
    zdm.dbcleanup.auditRetentionTimeInDays=1 day