Adobe LiveCycle ES2 Technical Guide Joel Lucuik, Senior Computer Scientist Adobe® LiveCycle® ES2 Performance Tuning Guide This document provides guidance to application architects and developers to help them monitor and measure the performance characteristics of a LiveCycle application. This includes the use of built-in tools and mechanisms as well as the use of third party tools to analyze performance. Introduction In this guide we describe LiveCycle parameters that can be used when adjusting LiveCycle to meet specific operational needs. This document is intended to be used by individuals with good technical knowledge of all Download Adobe® aspects of a LiveCycle environment. LiveCycle® ES2 http://www.adobe.com/ Each customer situation is unique with specific tuning requirements. LiveCycle’s Configuration Manager devnet/livecycle/trial.html configures LiveCycle with the default settings, which may be good for general purposes, but should be revisited periodically. Many LiveCycle Services can be individually tuned. Tuning LiveCycle typically involves monitoring the JVM(s), Adobe® LiveCycle® Data operating system, and database, then deciding what adjustments are necessary to improve system Services Home Page performance. Monitoring tools such as the LiveCycle Health Monitor and JConsole can provide information to http://www.adobe.com/ help with required decisions. products/livecycle/ LiveCycle’s “Bedrock layer” concepts are introduced within this guide to help tuning of the C/C++ components outside of the JVM. Adobe® LiveCycle® ES In order to tune third party software such as application servers, and in some cases, the JVM and database, you Developer Center may be referred you to 3rd party documentation. http://www.adobe.com/ devnet/livecycle/ Performance factors There are many factors to consider when tuning a LiveCycle ES2 application. Consider each of the following when approaching a tuning exercise: • The application design, the volume of form data, quantity of attachments, as well as signatures or annotations in the forms that are used in the process will affect the user-interactive experience and the database growth over time. • The presence of LiveCycle ES2 solution components, such as LiveCycle PDF Generator, or other components that are incorporated into processes will affect the performance of the servers. • Some LiveCycle Services make heavy use of the underlying database. The choice of database server, CPU, and disk I/O bandwidth available on the database server will greatly influence performance. • Other database factors, such as where the database runs (on the same server as LiveCycle ES2 or on a remote server), if there is a parallel database load from other applications, and the available bandwidth between LiveCycle ES2 and the database server. Questions or suggestions about this Tech Guide? Contact us directly at [email protected] • The amount of memory available on all servers. More complex or larger applications require more memory to service any single transaction. • The number and speed of the processors available on each server as well as the architecture of the processors. For example, Sun™ SPARC® and IBM® Power processors of nominally equal capacity do not perform equally for all LiveCycle applications. • The infrastructure architecture affects performance, including factors such as whether the server is single-tiered or multi-tiered, and if the architecture implements clustering or high availability. • The network bandwidth available between the application server and the desktop, or between the web server and the desktop. Network latency can affect the time it takes to transfer forms or data from the server to the desktop and vice versa, lengthening the overall response time. • Scalability factors, both over time and during peak hours. Significant factors affecting scalability include growth and variation of content, customers, users, and volume. • LiveCycle ES2 configuration settings for individual document services and core platform components. • The use of security systems such as firewalls, intrusion detection systems, content filters, disk encryption, and antivirus software on the server or the desktop. On servers in particular, antivirus software and the choice of antivirus settings or policies can cause significant degradation in performance. • Desktop infrastructure affects the performance of client-side components, in particular, the deployment of Adobe Reader and Workspace, which will affect the performance of a LiveCycle application from an end-user perspective. Desktop infrastructure factors include the speed of desktop systems, amount of memory available for the desktop, other desktop programs in use, as well as the version of Adobe Flash®, Adobe Reader®, or Adobe Acrobat® available on the desktop. Monitoring LiveCycle LiveCycle can be monitored by the Health Monitor or external tools such as JConsole or JVM logging. LCES Health Monitor The LCES Health Monitor is an interface delivered with LiveCycle that presents a health check of the internal details of the Java container. The Health Monitor can be found in the Administration Console at the top right on the menu bar. The Health Monitor provides two views: System, and WorkManager. System This view presents memory utilization, CPU utilization and other low level details. • OSName: Name of the Operating system where LiveCycle is deployed. • Up Time: Time in hours and minutes for which LiveCycle has been up. • Total Physical Memory: Physical memory of the system in MB. • Free Physical Memory: Available physical memory of the system in MB. • Free swap space size: Free swap space in MB. • Latest Heap: Currently used heap in MB of the system. • Latest Committed Heap: Current heap allocated to LiveCycle. • Latest Non Heap: Currently used non heap in MB of the system. • Latest Committed Non Heap: Allocated non heap to the system in MB. • Latest Number of Thread: Total number of threads currently present in the system. 2 Also included in the health monitor are historical charts. WorkManager This view presents the status of the work queues within LiveCycle, including successful, failed, total jobs, workflows, and events. JConsole The second method of monitoring the JVM is with JConsole. This is a JMX Console shipped with the Oracle JDK, the IBM JDK, and Oracle JRockit. JConsole connects to the JVM to provide real time heap information, Garbage Collection (GC) facilities, active thread and class counts among other details. Each JDK has its own heap layout and GC strategy. For the sake of simplicity, the authentication and encryption security mechanisms in the examples in this document are disabled. However, you should implement these security mechanisms when implementing remote management in real-world environments. JBoss, WebLogic, and WebSphere require configuration changes to allow JConsole to connect to them. 3 JBoss and WebLogic JBoss and WebLogic require the following configuration change to the startup script to permit JConsole to connect: -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote WebSphere To connect to WebSphere, the following steps are required: 1. Create a file containing the following property definitions: com.sun.management.jmxremote.port=8999 com.sun.management.jmxremote.authenticate=false com.sun.management.jmxremote.ssl=false // The port can be any available port (above 1024). 2. Modify the server JVM startup arguments by adding: -Djavax.management.builder.initial= -Dcom.sun.management.jmxremote -Dcom.sun.management.config. file=<path to file created in previous step> Heap Memory Usage JConsole provides low level memory statistics and basic graphing facilities to help you understand the behavior of the JVM heap and Operating System memory usage. One can easily profile memory during load testing of LiveCycle to determine behavior under load. The JVM can be monitored in real time during any kind of performance testing. This will not affect performance statistics. JConsole permits you to trigger a full GC clean-up to see the “net” state of the heap. The GC response may not be immediate. To learn more about JConsole, visit: http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html More detailed Memory usage documentation can be found on the Sun website: http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html#LowMemoryDetection 4 Memory Charting Memory charts are available in JConsole to help monitor activity in the JVM. Memory Charting Exporting Chart data can be exported in csv format for use in various reporting/charting tools. 5 Heap Dump JConsole provides heap dumping facility to help analyze the current state of the heap. Any tools that understands the “.hprof” format can be used to analyze the heap dump. One option is MAT, a plugin for Eclipse. See http://www.eclipse.org/mat/ for details. Eclipse facilities for analyzing a Heap Dump MAT is a free Memory Analyzer plugin for eclipse that is a fast and feature-rich Java heap analyzer that helps find memory leaks and reduce memory consumption. MAT can import: • .hprof: JConsole heap dump • .phd: output of “kill -3 [processId]” from a Solaris/WebSphere JDK with the help of the following plugin: http://www.ibm.com/developerworks/java/jdk/tools/dtfj.html For larger heap dumps consider adjusting the heap to -Xmx4096m in MemoryAnalyzer.ini. 6 JMX Facilities for Timing Processes LiveCycle stores execution times of core services and customer