|
Si vous rencontrez des problèmes de performance avec LiveCycle, envisagez les solutions suivantes :
Problèmes de synchronisation : si de nombreux threads sont en attente simultanément et dans la même partie du code, procédez à un vidage des threads une fois l’encombrement terminé.
Important : cette opération peut désactiver la JVM.
Ressources externes lentes : si de nombreux threads sont en attente d’un message de retour provenant d’une source externe, procédez à un vidage des threads d’exécution pour trouver celles qui sont en attente de sources telles que les bases de données ou les serveurs LDAP.
Collecte de GC lente : si verbosegc procède fréquemment à des compactages, réduisez la quantité de déchets générés par l’application en introduisant les pools d’objets ou la mise en cache. Si le journal indique de longs cycles de nettoyage de la mémoire dans verbosegc, réduisez la taille maximale.
Utilisation importante de l’unité centrale : si le niveau d’utilisation de l’unité centrale est supérieur ou égal à 75 %, envisagez d’effectuer les opérations suivantes :
Réduction de la taille de pool pour le conteneur Web ou les threads ORB.
Réduction du nombre de connexions de base de données sur le serveur de base de données.
Ajout de ressources de traitement (si le niveau d’utilisation de l’unité centrale est régulièrement élevé).
Réduction du paramètre de nombre maximal de connexions à la source de données, si l’unité centrale concernée se trouve sur le serveur de base de données.
Taille élevée du référentiel de banque de données : certaines opérations dans LiveCycle risquent d’entraîner une augmentation importante de la taille du référentiel de banque de données. Par exemple, dans la solution Correspondence Management, cette situation est susceptible de se produire si vous exécutez un processus de traitement par lots impliquant la publication d’un grand nombre d’actifs. Vous pouvez utiliser le garbage collector de la banque de données pour effacer toutes les données temporaires à partir du référentiel.
Pour exécuter le garbage collector de banque de données :
Accédez à http://<nom d’hôte>:<port>/lc/system/console/jmx et connectez-vous à l’aide d’informations d’identification d’administrateur.
Recherchez com.adobe.granit (saisissez Repository) et cliquez dessus.
Recherchez runDataStoreGarbageCollection(java.lang.Boolean delete) et cliquez dessus.
Définissez java.lang.Boolean delete sur true.
Cliquez sur Invoke pour exécuter le garbage collector.
Importation de packages avec grand nombre d’actifs : lorsque vous importez un package qui contient un grand nombre d’actifs, vous risquez de rencontrer le problème suivant :
erreur d’espace du tas Java
Pour résoudre ce problème, vous devez augmenter l’espace du tas Java à 4 Go.
Correspondence Management et les interfaces utilisateur CRX deviennent inaccessibles.
Il est conseillé de recourir à une opération de traitement par lots dans le cadre d’importations volumineuses.
Fonctionnement ralenti ou exception d’expiration de transaction lors de l’utilisation d’Administration Console* Nouveauté de la version 10 *
Si vous effectuez plusieurs opérations sur un grand nombre de fichiers à l’aide d’Administration Console, vous pouvez rencontrer des ralentissements de fonctionnement ou des exceptions d’expiration.
Pour résoudre ces problèmes, il vous faut augmenter la valeur du délai d’expiration de la transaction pour votre serveur d’applications. Pour définir la valeur du délai d’expiration de transaction, voir la documentation produit correspondant à votre serveur d’applications.
Amélioration des performances durant un appel de service asynchroneEchec de l’appel à distance avec des serveurs d’applications dans un environnement IPv6 purSi votre serveur LiveCycle est déployé dans un environnement IPv6 pur, l’appel des services à distance sur ce serveur peut échouer. Ce problème se produit en cas d’utilisation de JDK Sun avec les clients. Pour éviter cette erreur, utilisez le JDK IBM avec les clients lorsque LiveCycle est déployé sur des serveurs d’applications dans un environnement IPv6 pur.
Problème de performance de Process Management sur OracleLe débit de Process Management pour les bases de données Oracle se détériore parfois au fil du temps. L’équipe de développement de LiveCycle a élaboré des scripts SQL*Plus visant à résoudre ce problème. Ces scripts améliorent les performances dans les cas où le nombre d’utilisateurs est élevé.
Vous pouvez contacter le support aux entreprises d’Adobe et demander des scripts associés à la note technique intitulée « Problème de performance de Process Management sur Oracle » (ID de document cpsid_85089).
Amélioration des performances de Windows Server avec LDAPL’utilisation du pool de connexions sur la connexion de recherche peut réduire le nombre de ports requis de 50 %, car cette connexion utilise toujours les mêmes informations d’identification pour un domaine donné, et le contexte et les objets liés sont fermés de manière explicite.
Configurez Windows Server pour une mise en pool des connexionsDémarrez l’éditeur de registre en sélectionnant Démarrer > Exécuter et, dans le champ Ouvrir, saisissez regedit, puis cliquez sur OK.
Accédez à la clé de registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Dans le volet de droite de l’éditeur de registre, recherchez le nom de la valeur TcpTimedWaitDelay. Si le nom n’apparaît pas, sélectionnez Edition > Nouveau > Valeur DWORD pour l’ajouter.
Dans la zone Nom, saisissez TcpTimedWaitDelay.
Si vous ne voyez pas de point d’insertion et Nouvelle valeur # dans la zone, effectuez un clic droit dans le volet de droite, sélectionnez Renommer dans le menu puis, dans le champ nom, saisissez TcpTimedWaitDelay.
Répétez les étapes 4 et 5 pour les noms de valeur suivants : MaxUserPort, MaxHashTableSize et MaxFreeTcbs.
Cliquez deux fois dans le volet de droite pour définir la valeur TcpTimedWaitDelay ; sous Base, sélectionnez Décimale puis, dans le champ Valeur, saisissez 30.
Cliquez deux fois dans le volet de droite pour définir la valeur MaxUserPort ; sous Base, sélectionnez Décimale puis, dans le champ Valeur, saisissez 65534.
Cliquez deux fois dans le volet de droite pour définir la valeur MaxHashTableSize ; sous Base, sélectionnez Décimale puis, dans le champ Valeur, saisissez 65536.
Cliquez deux fois dans le volet de droite pour définir la valeur MaxFreeTcbs ; sous Base, sélectionnez Décimale puis, dans le champ Valeur, saisissez 16000.
Important : vous pouvez rencontrer de graves problèmes si vous modifiez le registre de manière incorrecte à l’aide de l’éditeur de registre ou d’une autre méthode. Vous pourriez être obligé de réinstaller votre système d’exploitation. Modifiez le registre à vos propres risques.
Configuration du service de programmation (Scheduler) pour les URL JNDI autres que les URL par défaut(Environnements non groupés uniquement)
Il est possible que vous deviez configurer plus avant le service de programmation (Scheduler) pour lui permettre de fonctionner correctement.
JBossSur JBoss, si l’URL JNDI est différente de l’URL JNDI par défaut pour le serveur d’applications (pour JBoss : jnp://localhost:1099), il s’agit de l’URL JNDI de IDP_DS qui est gérée par votre serveur d’applications :
org.quartz.dataSource.idp.java.naming.provider.url
Créez un fichier appelé dscscheduler.properties.
Définissez les valeurs des propriétés ci-dessus selon les besoins pour le nœud de serveur d’applications, comme suit :
org.quartz.dataSource.idp.java.naming.provider.url =
jnp://localhost:1099/
org.quartz.jobstore.isClustered = true
org.quartz.scheduler.instanceId = AUTO
Ajoutez l’argument JVM -Dadobe.idp.scheduler.properties=[Chemin vers ce fichier]/dscscheduler.properties aux scripts/à la configuration de démarrage du serveur d’applications.
WebSphereSur WebSphere, si l’URL JNDI est différente de l’URL JNDI par défaut pour le serveur d’applications (pour WebSphere : iiop://localhost:2809), il s’agit de l’URL JNDI de IDP_DS qui est gérée par votre serveur d’applications :
org.quartz.dataSource.idp.java.naming.provider.url
Créez un fichier appelé dscscheduler.properties.
Définissez les valeurs des propriétés ci-dessus selon les besoins pour le nœud de serveur d’applications, comme suit :
org.quartz.dataSource.idp.java.naming.provider.url =
iop://localhost:2809/
org.quartz.jobstore.isClustered = true
org.quartz.scheduler.instanceId = AUTO
Ajoutez l’argument JVM -Dadobe.idp.scheduler.properties=[Chemin vers ce fichier]/dscscheduler.properties aux scripts/à la configuration de démarrage du serveur.
WebLogicSur WebLogic, si l’URL JNDI est différente de l’URL JNDI par défaut pour le serveur d’applications (pour WebLogic : t3://localhost:7001), il s’agit de l’URL JNDI de IDP_DS qui est gérée par votre serveur d’applications :
org.quartz.dataSource.idp.java.naming.provider.url
Créez un fichier appelé dscscheduler.properties
Définissez les valeurs des propriétés ci-dessus selon les besoins pour le nœud de serveur d’applications, comme suit :
org.quartz.dataSource.idp.java.naming.provider.url =
t3://localhost:7001/
org.quartz.jobstore.isClustered = true
org.quartz.scheduler.instanceId = AUTO
Ajoutez l’argument JVM -Dadobe.idp.scheduler.properties=[Chemin vers ce fichier]/dscscheduler.properties aux scripts/à la configuration de démarrage du serveur d’applications.
Problème de performances et de journalisation excessive d’API FileNet sur WebLogicLorsque LiveCycle est installé sur un serveur WebLogic, les API IBM® FileNet peuvent rencontrer des problèmes de performance en raison de la journalisation excessive. Pour améliorer les performances dans ces cas, vous devez modifier le niveau de journalisation de « debug » en « Fatal ».
Sur FileNet Content Server, accédez au répertoire C:\Program Files\FileNet\ContentEngine\config\samples.
Copiez le fichier log4j.properties.client sur le serveur LiveCycle et renommez-le log4j.properties.
Ouvrez le fichier log4j.properties et commentez les entrées des Appenders FileNetTraceAppender et FileNetTraceRollingAppender: #=== FileNetTraceAppender
log4j.appender.FileNetTraceAppender=org.apache.log4j.FileAppender log4j.appender.FileNetTraceAppender.File=/p8_api_trace.log # This is the layout that the TraceLoggingConfiguration framework on the server uses.
# To use this layout , jace.jar must be present in the classpath. #log4j.appender.FileNetTraceAppender.layout=com.filenet.apiimpl.util.TraceLayout # Comment out the following lines if using the FileNet TraceLayout log4j.appender.FileNetTraceAppender.layout=org.apache.log4j.PatternLayout log4j.appender.FileNetTraceAppender.layout.ConversionPattern=%d %5p [%t] - %m\r\n #=== FileNetTraceRollingAppender log4j.appender.FileNetTraceRollingAppender=org.apache.log4j.RollingFileAppender log4j.appender.FileNetTraceRollingAppender.File=/p8_api_trace.log log4j.appender.FileNetTraceRollingAppender.MaxFileSize=100MB log4j.appender.FileNetTraceRollingAppender.MaxBackupIndex=1
# This is the layout that the TraceLoggingConfiguration framework on the server uses.
# To use this layout , jace.jar must be present in the classpath.
#log4j.appender.FileNetTraceRollingAppender.layout=com.filenet.apiimpl.util.TraceLayout
# Comment out the following lines if using the FileNet TraceLayout
log4j.appender.FileNetTraceRollingAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.FileNetTraceRollingAppender.layout.ConversionPattern=%d %5p [%t] - %m\r\n
Enregistrez le fichier log4j.properties.
Ajoutez le chemin d’accès au dossier contenant le fichier log4j.properties sur l’entrée d’ID de composant FileNet présent dans le fichier adobe-component-ext.properties qui se trouve sur le serveur d’applications LiveCycle. Dans le serveur d’applications WebLogic, ce fichier se trouve dans [WL_HOME]/user_projects/domains/<nom de domaine>.
Par exemple, si le fichier log4j_file/log4j.properties est stocké à l’emplacement : C:/log4j_file/log4j.properties, ajoutez « C:/log4j_file » au fichier adobe-component-ext.properties.
Redémarrez le serveur d’applications.
Avertissement d’expiration de l’article de mémoire cache lorsque de nombreux utilisateurs accèdent simultanément à Content Services (obsolète)Remarque : Adobe procède actuellement à la migration des clients Adobe® LiveCycle® Content Services ES vers le référentiel de contenu Content Repository basé sur l’architecture modulaire CRX moderne, acquise par Adobe lors de son rachat de la société Day Software. Content Repository est fourni avec LiveCycle Foundation et il est disponible à compter de la version LiveCycle ES4.
Le message d’avertissement suivant peut apparaître dans les journaux du serveur d’applications lorsque plusieurs utilisateurs tentent d’accéder simultanément à Content Services :
ReadWriteCach W org.hibernate.cache.ReadWriteCache handleLockExpiry An item was expired by the cache while it was locked (increase your cache timeout): org.alfresco.repo.domain.hibernate.NodeImpl.properties
Pour résoudre ce problème, définissez l’argument JVM suivant dans les scripts de démarrage du serveur d’applications pour utiliser l’algorithme LRU (Least Frequently Used) au lieu de l’algorithme heuristique par défaut pour actualiser ehcache :
-Dnet.sf.ehcache.use.classic.lru=true
|
|
|
