Performance considerations

If you are experiencing performance issues with LiveCycle, consider the following:

  • Synchronization issues: If many threads are waiting at the same time in the same part of the code, obtain a thread dump when the congestion passes.

    Important: Thread dumps may disable the JVM.

  • Slow external resources: If many threads are waiting for a return message from an external source, obtain a thread dump to find threads that are waiting for sources such as databases or LDAP servers.

  • Slow GC collection: If verbosegc performs compaction frequently, reduce the amount of garbage generated by the application by introducing object pooling or caching. If the log shows long garbage collection cycles in verbosegc, reduce the maximum heap size.

  • High user CPU: If your CPU is running at 75% or higher, consider these options:

    • Reduce the pool size of the web container or ORB threads.

    • Reduce the number of database connections on the database server.

    • If you experience consistently high CPU usage, consider adding processing resources.

    • If the CPU is on the database server, reduce the datasource maximum connection setting.

    Slow performance or transaction timeout exception while using Administration Console

    * New for 10*

    If you are performing multiple operations on large number of files using Administration Console, you might experience slow performance or receive the Timeout exception.

    To resolve this issue, you must increase the transaction timeout value for your application server. To configure the transaction timeout value, see the product documentation for your application server.

    Improving performance during asynchronous service invocation

    For improving performance during asynchronous invocation of services, set the following JVM arguments:

    • -Dadobe.work-manager.queue-refill-interval=1

    • -Dadobe.workmanager.memory-control.enabled=false

    For JBoss, add these arguments to:

    • (Windows) the run.bat, or the run.conf.bat file as per your JBoss installation.

    • (UNIX)the run.sh, or the run.conf file as per your JBoss installation.

    See “Configuring the JVM arguments” in the Installing and Deploying LiveCycle for WebSphere guide for information on setting JVM arguments for WebSphere.

    See “Configuring the JVM arguments” in the Installing and Deploying LiveCycle for WebLogic guide for information on setting JVM arguments for WebLogic.

    Remote invocation fails with application servers on pure IPv6

    If your LiveCycle server is deployed in a pure IPv6 environment, remote invocation of services on the LiveCycle server might fail. This is an issue with Sun JDK used with the clients. To avoid this error, use the IBM JDK with clients when LiveCycle is deployed on application servers in a pure IPv6 environment.

    Process Management performance issue on Oracle

    Process Management throughput for Oracle databases is sometimes observed to deteriorate over time. The LiveCycle development team has made some SQL*Plus scripts available to help resolve this issue. These scripts improve performance in scenarios having a large number of users.

    You can contact Adobe Enterprise Support and ask for scripts associated with the TechNote titled "Process Management performance issue on Oracle" (document ID cpsid_85089).

    Improving Windows Server performance with LDAP

    Using connection pooling on the search connection can decrease the number of ports needed by as much as 50% because that connection always uses the same credentials for a given domain, and the context and related objects are closed explicitly.

    Configure Windows Server for connection pooling

    1. Start the registry editor by selecting Start > Run and, in the Open box, type regedit, and then click OK.

    2. Go to the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

    3. In the right pane of the registry editor, look for the TcpTimedWaitDelay value name. If the name does not appear, select Edit > New > DWORD Value to add it.

    4. In the name box, type TcpTimedWaitDelay.

    5. If you do not see an insertion point and New Value # inside the box, right-click inside the right panel, select Rename from the menu and then, in the name box, type TcpTimedWaitDelay.

    6. Repeat steps 4 and 5for the following value names: MaxUserPort, MaxHashTableSize, and MaxFreeTcbs.

    7. Double-click inside the right pane to set the TcpTimedWaitDelay value; under Base, select Decimal and, in the Value box, type 30.

    8. Double-click inside the right pane to set the MaxUserPort value; under Base, select Decimal and, in the Value box, type 65534.

    9. Double-click inside the right pane to set the MaxHashTableSize value; under Base, select Decimal and, in the Value box, type 65536.

    10. Double-click inside the right pane to set the MaxFreeTcbs value; under Base, select Decimal and, in the Value box, type 16000.

    Important: Serious problems may occur if you modify the registry incorrectly by using Registry Editor or by another method. These problems may require that you reinstall your operating system. Modify the registry at your own risk.

    Scheduler service configuration for nondefault JNDI URLs

    To function correctly, the Scheduler service may require some additional configuration.

    JBoss

    On JBoss, if the JNDI URL differs from the default JNDI URL for the application server (that is, for JBoss: jnp://localhost:1099), this is the JNDI URL for the IDP_DS that is managed by your application server:

        org.quartz.dataSource.idp.java.naming.provider.url

    1. Create a new file named dscscheduler.properties.

    2. Set the values of the above properties as necessary for the app server node, such as the following text:

              org.quartz.dataSource.idp.java.naming.provider.url =  
            jnp://localhost:1099/ 
        (clustered environments only) org.quartz.jobStore.isClustered = true 
        (clustered environments only) org.quartz.scheduler.instanceId = AUTO

    3. Add the JVM argument -Dadobe.idp.scheduler.properties=[Path to this file]/dscscheduler.properties to the application server startup scripts/configuration.

    WebSphere

    On WebSphere, if the JNDI URL differs from the default JNDI URL for the application server (that is, for WebSphere: iiop://localhost:2809), this is the JNDI URL for the IDP_DS that is managed by your application server:

        org.quartz.dataSource.idp.java.naming.provider.url

    1. Create a new file called dscscheduler.properties

    2. Set the values of the above properties as necessary for the app server node, such as the following values:

              org.quartz.dataSource.idp.java.naming.provider.url =  
            iop://localhost:2809/ 
        (clustered environments only) org.quartz.jobStore.isClustered = true 
        (clustered environments only) org.quartz.scheduler.instanceId = AUTO

    3. Add the JVM argument -Dadobe.idp.scheduler.properties=[Path to this file]/dscscheduler.properties to the application server startup scripts/configuration.

    WebLogic

    On WebLogic, if the JNDI URL differs from the default JNDI URL for the application server (that is, for WebLogic: t3://localhost:7001), this is the JNDI URL for the IDP_DS that is managed by your application server:

        org.quartz.dataSource.idp.java.naming.provider.url

    1. Create a new file named dscscheduler.properties

    2. Set the values of the above properties as necessary for the app server node, such as the following values:

              org.quartz.dataSource.idp.java.naming.provider.url =  
            t3://localhost:7001/ 
        (clustered environments only) org.quartz.jobStore.isClustered = true 
        (clustered environments only) org.quartz.scheduler.instanceId = AUTO

    3. Add the JVM argument -Dadobe.idp.scheduler.properties=[Path to this file]/dscscheduler.properties to the application server startup scripts/configuration.

    FileNet API excessive logging and performance issues on WebLogic

    For LiveCycle installed on a WebLogic Server, IBM® FileNet APIs might experience performance issues owing to the excessive logging. To improve the performance in such cases, you should change the logging level from 'debug' to 'Fatal'.

    1. On FileNet Content Server, navigate to the C:\Program Files\FileNet\ContentEngine\config\samples directory.

    2. Copy the log4j.properties.client file to the LiveCycle server machine and rename it to log4j.properties.

    3. Open the log4j.properties file and comment out the entries for the appenders FileNetTraceAppender and 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

      • Set FileNet logger to FATAL and remove FileNetTraceAppender and FileNetTraceRollingAppender from the logger:

        Replace 
        log4j.logger.filenet_error = error, FileNetConsoleAppender, 
FileNetErrorRollingAppender, FileNetTraceRollingAppender

        with 

        log4j.logger.filenet_error = fatal, FileNetErrorRollingAppender

      • Set FileNet API logger to FATAL:

        Replace 

        #log4j.logger.filenet_error.api = warn

        with 

        log4j.logger.filenet_error.api = fatal

    4. Save the log4j.properties file.

    5. Add the path of the folder containing the log4j.properties file to the FileNet Component ID entry present in the adobe-component-ext.properties file placed in the LiveCycle application server. In WebLogic application server, this file is in [WL_HOME]/user_projects/domains/<domain name>.

      For example, if log4j.properties file is stored at location: 'C:/log4j_file/log4j.properties', then add "C:/log4j_file" to the adobe-component-ext.properties file.

    6. Restart the application server.

    Cache item expiry warnings when many concurrent users are accessing Content Services (deprecated)

    Note: Adobe is migrating Adobe® LiveCycle® Content Services ES customers to the Content Repository built on the modern, modular CRX architecture, acquired during the Adobe acquisition of Day Software. The Content Repository is provided with LiveCycle Foundation and is available as of the LiveCycle ES3 release.

    The following warning message may appear in the application server logs when multiple concurrent users are accessing 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

    To resolve this issue, set the following JVM argument in the application server startup scripts to use the Least Recently Used (LRU) algorithm instead of the default heuristic algorithm to refresh ehcache:

    -Dnet.sf.ehcache.use.classic.lru=true

    Repository is not starting due to repository lock issue

    The following warning message may appear if the repository is not starting due to a repository lock issue:

    *WARN * RepositoryLock: Existing lock file /apps/AdobeAuth/AdobeAuth-2/crx-repository/crx.0002/.lock detected. Repository was not shut down properly. (RepositoryLock.java, line 134) [10/9/12 14:47:00:594 MDT] 00000009 SystemOut     O 09.10.2012 14:47:00 *ERROR* CRXRepositoryStartupServlet: Unable to create repository. (CRXDiagnostic.java, line 369)

    This issue is encountered when multple instances deployed on a machine use the same repository. You need to ensure that all instances deployed on a machine, use a separate repository.

    Even if you have configured a separate repository for each instance, the instances might still be using the same repository. This is because of the presence of bootstrap.properties file. This file contains repository information that overrides any predefined repository configuration. The properties file is created on slave instances while creating shared nothing cluster using the cluster.jsp. The properties file is created in the user directory that is different for each appserver.

    The location of the bootstrap.properties for each appserver is as follows:

    JBoss
    <JBoss_HOME>/bin

    WAS
    <WAS_HOME>/profiles/<PROFILE_NAME>

    WebLogic
    <WL_HOME>/user_projects/domain/<DOMAIN_NAME>

    A server running under a particular JBoss installation, WebSphere Profile or Weblogic Domain join a shared nothing cluster as slave would definitely create bootstrap.properties file in user directory as listed above. The properties file defines repository configuration for the slave instance. Any other instance running under the same installation, profile, or domain would have access to the properties file that is defined for another slave instance. These instances will read repository configuration for other slave instances and try to access the slave instance repository. This leads to repository lock issue.

    To prevent the repository lock issue, it is recommended that you run all instances under different installations, profiles, or domains. This is required if each such configuration contains a slave instance. If you need to run multiple instances under the same configuration, you need to perform manual updates to avoid the repository lock issue. For instances other than the slave running on the same configuration, you need to make the following changes.

    1. Open adobe-livecycle-<appserver-name>.ear.

    2. Open crx-explorer_crx.war

    3. Open WEB-INF/web.xml.

    4. Find the bootstrap-config section and change the value bootstrap.properties to bootstrap1.properties or some other name.

    5. Repackage the war and ear files.

    6. Deploy the ear file to server.

    // Ethnio survey code removed