Cache Configuration Options
The Forms and Output caches have a number of configuration settings for tuning LiveCycle for a specific use
case. In general, the default settings are suitable for most situations but it may be necessary to tune the cache
size in order to limit memory usage. It will be beneficial to understand the cache operation when designing
certain types of applications that create or manipulate form templates. For additional information, refer to:
Tuning the Forms service involves tuning the these components:
• Template Cache: Cache for raw documents such as XDPs.
• Template Conﬁguration Cache: Parsed versions of the Template Cache.
• Form Rendering Cache: Stores the ﬁnal versions of documents being rendered
• Image Cache: Images cache that assists the construction of the entries in the Resolved Template Cache.
In the AdminUI cache settings can be found in “Home , Services, LiveCycle Forms ES2” under Cache Control
Forms Cache Control Settings
• “Only if their last validation was done prior to cache check point time”
In this mode, the Forms service only checks the repository for newer versions of resources when the
timestamp of the cached resource is older than the cache check point time. In a high-performance
production environment where performance is a concern and changes to resources are infrequent, you
can reset the cache check point time when you want to deploy any changes made to the repository
Max Cache Document Size
This parameter specifies the maximum size a document that can be stored in any in-memory cache. This is a
global setting and applies to all in-memory caches but does not impact the disk cache.
Logs entries are produced when large documents are not cached in the in-memory cache due to the Max
Document size being low:
14:35:18,364 WARN [CacheManager] Ignoring cache write as Object size is greater than Max Document size in
cache setting. Key [c:\FormsServer\Forms\LCF-1.xdp] and Size 
14:35:20,598 WARN [CacheManager] Ignoring cache write as Object size is greater than Max Document size in
cache setting. Key [C:\jbossturnkey\server\all\svcdata\FormServer\Cache\1253284221285\Disk_
Cache\C%3A%5FormsServer%5CForms\LCF-1.xdp-Resources\LCF-1.c.xdp.cch] and Size 
Form Rendering Cache Enabled
Selected by default, rendered forms are cached for subsequent retrieval. This setting improves performance
because the Forms service only has to render each form once. This option works in conjunction with the form
design’s caching property.
In Memory Template and In Memory Form Rendering Cache(s)
These settings provide the ability to configure the size of the caches for the following:
• Template Conﬁguration Cache: Caches parsed versions of the Template Cache.
• Template Cache: Caches raw documents such as XDPs.
• Form Rendering Cache: Caches the ﬁnal versions of the document being rendered
Template Resource Cache
This configures the size of the cache for the following:
• Template Resource Cache: Images are cached. 周is assists the construction of the entries in the Template
Configuring BMC pool size
One critical aspect of tuning Forms or Output is to ensure the XMLForm BMC pool is properly sized. See Tuning
C/C++ “Bedrock” Components for detailed information on bedrock managed components and tuning
The output service is a document generation engine that generates PDF, PDF/A, PostScript®, PCL, or Zebra label
formats. It can also merge XML data from back‐end systems with Designer ES templates or convert PDF files to
print or image file formats, and then route these automatically to support direct server-based printing or
OutputService Transaction Time Out
OutputService transaction timeout determines the amount of time that a transaction is given before LiveCycle
aborts the transaction. The default is 300 seconds.
If you are printing a large document (> 1000 pages for example), it may exceed the 300 second default. A
system printing many large documents will need a larger timeout to allow these documents to print without
To change this option, go to “Administration Console, Services, Archive Administration, Service Management,
Configuring BMC pool size
One critical aspect of tuning Output is to ensure the XMLForm BMC pool is properly sized. Details on this
parameter are mentioned in the Tuning C/C++ “Bedrock” Components section of this document.
Tuning PDF Generator
PDFG Supports multithreading for the following converters:
• Native2PDF Converter (only MS Word and MS PowerPoint)
• OpenOﬃce2PDF Converter
To configure the pools for multithreading (section “A” above) go to the administration console:
For HTML and Image to PDF navigate to ““Home, Services, Applications and Services, Service Management,
Configure GeneratePDFService, Configuration”.
Make changes under
• ImageToPDF Pool Size
• HTML to PDF Pool Size
For PostScript to PDF navigate to “Home, Services, Applications and Services, Service Management, Configure
DistillerService, Configuration”. Change the value under “Pool Size”.
To configure the pools for multithreading (section “B”), each thread requires its own user account. To manage
PDFG user accounts and add user accounts, navigate to “Home, Services, LiveCycle PDF Generator ES2, User
and add the valid administrative user accounts.
A server restart is recommended after this change.
Tuning PDFg 3D
PDFg3D does support a multithreaded environment. To configure the pools for this environment, go to the
administration console and navigate to “Home, Services, Applications and Services, Service Management,
Configure Generate3dPDFService, Configuration”.
Increase the value of “Pool Size”. In order to have threads work properly you will need to provide enough
“desktop heap memory” for these threads. To make this change, update the value of the windows registry
“HKEY_LOCAL_MACHINE \System\CurrentControlSet\Control\Session Manager\SubSystems” key (of
Windows SharedSection (Kb) for non-interactive mode, third value of comma separated values) as mentioned
on http://support.microsoft.com/kb/126962/. A server restart is required after this change.
The environment variable “A3DREVIEWER_MULTI” should be set to “1”. Setting this environment variable is
normally adjusted by LCM during PDFG configuration. To force this change, run Acrobat_for_PDFG_
Configuration.bat under <LC Home>/pdfg_config.
Tuning C/C++ “Bedrock” Components
Tuning parameters exist to tune the C/C++ components of Forms and Output. These are referred to as
“Bedrock”, or “Bedrock Managed Components” (BMCs).
Bedrock Managed Components (BMCs)
LiveCycle Forms and Output leverage code libraries that are implemented in C and C++ compiled to platform
native code. Sharing code between the LiveCycle Designer, Adobe Reader, and LiveCycle Forms enables a
higher level of compatibility between these products across the entire LiveCycle suite and is more efficient
than using a separate Java implementation.
The server architecture on which LiveCycle Forms is based is designed to increase the overall reliability of a
LiveCycle application. One key aspect of this, is the implementation of the XMLForm C++ processes which are
designed to be re-started periodically. Overall, in the LiveCycle server architecture, the Java environment is
shielded from the native code in a number of aspects:
• 周e native code is run out-of-process and communicates to Java via CORBA rather than running
in-process via JNI. 周is insulates the JVM from any possible problems occurring in the native code
• 周e native code components are actively managed and re-started when they fail.
Management of native code libraries by these methods is not unique to Adobe products. For additional
examples, see http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/.
POOL_MAX and MAXIMUM_REUSE_COUNT
The default values of these parameters are close to optimal for a wide range of applications. Here are two more
commonly used BMC settings for ConvertPDF and XMLForm:
The number of CPUs to be used for PDF conversion. This should never be more than twice the number of
logical CPUs, and never less than 2. The default is 4. Typically PDF conversion takes up to 90% of the CPU,
leaving another 10% available for another conversion.
The number of transactions allocated to ConvertPDF. After the count is reached this BMC is restarted. The
default is 10000.
The number of CPUs to be used for form rendering. As with ConvertPDF, this should never be more than
twice the number of logical CPUs, and never less than 2. Typically form rendering takes up to 90% of the
CPU, leaving another 10% available for another render. The default value is 4.
• com.adobe. xmlform.bmc.MAXIMUM_REUSE_COUNT=10000
The number of transactions allocated to XMLForm. When the count is reached, this BMC is restarted. The
default is 10000. Both com.adobe.convertpdf.bmc.POOL_MAX and com.adobe.xmlform.bmc.POOL_
MAX effectively share CPUs. If both are in use, and there are 8 CPUs available, start a tuning exercise
giving 4 CPUs to each of convertpdf and xmlform. If only 1 (of converpdf/xmlform) is in use, allocate all 8
CPUs to the process, and proceed to tune from that point.
Tuning the Database
Database tuning typically requires significant time and effort monitoring various areas within the database.
Consulting with a DBA is worthwhile to ensure database use is maximized. Details in this section are mostly
high level all available tuning options are not covered.
This attribute refers to the size in bytes of the memory buffer InnoDB used to cache data and indexes of its
tables. The default value is 8MB. The larger this value is set, the less disk I/O is needed to access data in tables.
On a dedicated database server, this can be set up to 80% of the machine physical memory size. However, it
should not be set too large because competition for physical memory may cause paging in the operating
The MySql path & filename for database storage on Windows with a turnkey installation is “
Move Redo Logs to Solid State Drives
When processing large amounts of form data you may encounter significant log wait times and log switching.
This can reduce the throughput of LiveCycle.
In order to increase throughput and reduce wait times for redo log buffer waits, moving the redo logs to solid
state drives may result in improved performance. See http://www.dba-oracle.com/t_redo_log_tuning.htm for
Disperse Files over Multiple Hard Drives
When creating the tablespaces and logs for Oracle, it is recommended that they not be placed on drives that
contain the operating system, page files, or swap files. If possible spread out the tablespace/datafiles over
multiple physical drives.
Gather Table Statistics
In order to obtain the best performance from your database, index table statistics should be gathered. For
further information on setting up an automated process to gather statistics refer to:
SGA (system global area) size
It is recommended that the Automatic Memory Management feature be enabled. This item is located in the
Server tab of Enterprise Manger. This feature allows oracle to shrink/grow the size of the SGA depending on
Sizing redo logs
If the redo log switching event is causing waits including alerts in enterprise manager, the size of the redo logs
should be increased. Having redo logs that are too large is likely not an issue, but if they are undersized,
frequent log file switching will occur as they fill.
In depth database performance tuning
If you are not comfortable performing the database tuning, use the services of a Database Administrator. There
are tunable items in the database parameter files that can result in severe performance degradation if they are
In most cases it is recommended that memory management be set to automatic. This applies to the heap
caches and memory sizes found in the configuration parameters accessed through the DB2 control center.
If at all possible distribute your tablespaces on physical devices that are not shared by the operating system
files, or page/swap files. This greatly reduces I/O contention.
If possible, create the database file group on a physical device that is not shared by the operating system files
or swap/page files.
Various technologies and 3rd party applications can be leveraged to help analyze problems, monitor systems
and diagnose failures. Some of these tools are useful for analyzing faults while others are useful for
pre-production testing and validation. Since loading some of these tools onto a production server that is
exhibiting a problem may not always be possible, it is recommended that the following subset of tools be
loaded onto production servers in advance of deployment.
• JProbe or YourKit
• JConsole or VisualVM
• Zenoss or Hyperic
Likely the easiest load generation tool to use, JMeter is an open source tool developed by theApache Jakarta
Project. Once an application has been built, JMeter can be used to simulate a load against the server by
invoking an end point. This will provide valuable insight into the stability and performance of an application.
Flex based end points are not currently supported in JMeter.
Grinder is an open sourceload testing framework. It is more powerful than JMeter but is not well suited for fast
ad-hoc testing. It can be scripted using Jython, and as with JMeter, you can leverage Grinder to build realistic
SilkPerformer is a product from MicroFocus. It is marketed as an enterprise-class tool for software application
performance and load testing. With SilkPerformer, you can create realistic load tests for thousands of users
running business scenarios across a broad range of enterprise application environments to identify
bottlenecks, and then apply diagnostics to resolve performance issues.
SilkPerformer has Flex/AMF3 support and transforms AMF3 traffic into a human-readable XML during script
recording and playback.
NeoLoad is a load testing software designed for Web applications, realistically simulating users and analyzing
your servers’ behavior.
NeoLoad’s technology allows you to answer specific questions such as: Does your web application function
properly under load, do the response times meet your target requirements, and what number of simultaneous
users can your website safely handle.
soapUI provides a test framework for web services, JMS, JDBC, and AMF technologies which comprise a large
set of the LiveCycle core technologies.
JProbe is a tool for determining which parts of your application are consuming the most memory. It is useful
for diagnosing application server memory issues including “out of memory”. It also profiles garbage collection
trends. JProbe is particularly useful when building and deploying custom components or applications that
Provides similar capabilities to JProbe for memory profiling but also provides processor profiling.
DynaTrace can provide assistance when designing and developing large scale systems that use LiveCycle and a
complete end-to-end performance management system is required. This tool is designed for large scale
custom development efforts.
JConsole is released as a part of the Java JDK and provides a means to monitor running Java processes.
JConsole provides a free and fast Java process monitor. It is used extensively when monitoring LiveCycle to
capture memory, CPU and garbage collection trends but it also provides valuable thread statistics along with
Provides similar capabilities to JConsole but adds additional control mechanisms that system administrators
can benefit from.
JRockit Mission Control
JRockit allows you to monitor and profile memory consumption in a running Java application. This tool can be
very useful for monitoring of custom LiveCycle applications to identify where the system is consuming the
largest amount of resources allowing optimizations where needed.
Hyperic provides a host of product monitoring and analytical solutions to cover an entire infrastructure. It
provides application server specific plug-ins for LiveCycle supported platforms.
Zenoss provides a number of application monitoring tools including network, server, and cloud deployments.
This tool provides similar capabilities to Hyperic, offering a complete, end to end monitoring solution with
alerts and analytical data gathering.
Memory Analyzer (MAT)
An Eclipse based memory analyzer that provides a closer look into heap dumps to understand where memory
is being consumed.
Provides real time log monitoring in an easy to use Windows based client.
A text editor with many features including easy viewing and filtering of very large log files.
Fiddler can capture http and https network traffic while also permitting change to data in-flight.
Similar to Fiddler, but additionally helpful in capturing http and https network traffic to better understand and
debug complex client to server interactions.
LCES: LiveCycle Enterprise Server
In the context of this document, this refers to the LiveCycle server deployed within the scope of an application
server. It is independent of the application server, database, and operating system. In the same context, the
term “LC” refers to the complete combination of application server, LCES, database and operating system.
A document object is an intelligent byte container. It is used extensively in all parts of LiveCycle to contain
varying bytes of all types.
GDS: Global Document Storage
GDS provides storage for long-lived documents, or documents shared between cluster members. The location
of the GDS can be system file storage or database.
Max Inline Size
Max Inline Size is the size of the per-document in-memory buffer that holds document objects being used by a
LiveCycle process with a default setting of 65536 bytes (64 KB). When processing a document larger than the
default value, file I/O occurs on the file system that hosts either the temporary folder or the GDS.
Local Document Storage
Used for storing documents that do not need to be persisted or shared. Located in the temporary folder, and is
separate for each node in a cluster. Configured with the LiveCycle Configuration Manager.
DSC: Document Service Component
A module deployed to the LiveCycle server. Each DSC contains one or more LiveCycle Services including
services such as PDFg, Output, Forms, etc. These may also be custom developed, referred to as Custom DSCs.
CS: Content Services
The Adobe® LiveCycle® Content Services ES2 module extends your investment in other LiveCycle ES2 modules,
enabling you to build content-rich applications rapidly with a low total cost of ownership. It provides a fully
integrated set of content services, ranging from an enterprise content repository to social collaboration tools.
Adobe® LiveCycle® Foundation provides the underlying server capabilities that enable the deployment,
execution, and management of LiveCycle ES2 modules. Included with most of the LiveCycle ES2 modules,
LiveCycle Foundation consists of:
• Service container
• Foundation services
• Administration tools
• Central repository
Use LiveCycle Foundation to deploy short-lived processes that combine a number of modules. For example,
you can create a PDF form, apply a security policy to it, certify the document, and enable the form for basic
form fill-in and import/export of data using Adobe Reader® software. A short-lived process can be reused in
other processes once it has been created. It can also be invoked by a number of different mechanisms. For
developers, a process can be invoked through a Java™ API, web services, and Microsoft .NET. LiveCycle
software supports the WS-I Basic Profile 1.1 standard and has tested interoperability with .NET and the web
services stacks supported by the major application server vendors as well as that found within the Sun™ Java
Software Development Kit (SDK). LiveCycle ES also allows developers of Adobe Flex® software using
ActionScript® to directly invoke processes (as well as modules) through the Adobe LiveCycle Data Services ES2
module. Other common forms of invocation include watched folders and e-mail.
Bedrock, or Bedrock Managed Components (BMCs)
C/C++ components of Forms and Output.
An assembly of actions representing a business workflow.
Entry point to a service or process.
A process where data within that process must be persisted during execution.
A process where no data within the process persists during execution.
JVM: Java Virtual Machine
The virtual machine where LiveCycle applications are deployed.
GC: Garbage Collection
A form of automatic memory management.
Documents you may be interested
Documents you may be interested