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 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.

  • High datastore repository size: Some operations in LiveCycle can cause a substantial increase in the size of the datastore repository. For example, in the Correspondence Management Solution, this can occur if you run a batch process that involves publishing a large number of assets. You can use the datastore garbage collector to clear out any temporary data from the repository.

    To run the datastore garbage collector:

    1. Navigate to http://<hostname>:<port>/lc/system/console/jmx and log in with administrator credentials.

    2. Search and click com.adobe.granite (type Repository).

    3. Search and click runDataStoreGarbageCollection(java.lang.Boolean delete).

    4. Set java.lang.Boolean delete to true.

    5. Click Invoke to run the garbage collector.

  • Importing package with large number of assets: When you import a package that contains a large number of assets, you may experience the following issue:

    • Java Heap Space error

      To resolve this issue, you need to increase the Java Heap space to 4GB.

    • Correpondence Management and CRX user interfaces become inaccessible.

      It is recommended that you perform large import processes in a batch operation.

    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

    (Non-clustered environments only)

    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/ 
        org.quartz.jobstore.isClustered = true 
        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/ 
        org.quartz.jobstore.isClustered = true 
        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/ 
        org.quartz.jobstore.isClustered = true 
        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 ES4 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

    // Ethnio survey code removed