Performance Tuning Tips for Faster LiveCycle Output

By considering the settings mentioned here, one can optimize the performance of LiveCycle output component and get better throughput.

Maximum Inline Size

A good starting point is to choose an optimal value of Max Inline Size.

Max inline size (bytes) setting can be found in LiveCycle Administration console under Home -> Settings -> Core System ->  Configurations, and it’s default value is set as 64K. Files larger than 64K are stored in the GDS, and files smaller are stored on the heap. The benefit of this behavior is that we can avoid keeping very large objects in the heap and it reduces the overall memory requirement of the JVM.

So the key point is to keep the file size small and set the Max Inline size a bit higher than the file size, that ensures fast output via Output DSC.

Also note that keeping very large objects in the heap can hamper the application’s performance as these objects can quickly take up a large part of the heap and can trigger frequent garbage collections.

Heap Consideration

To understand the heap requirement of the application, we can use JConsole tool and monitor the heap usage of the system. It is important to find the heap size that you need, and not specify a much larger heap “just to be safe” <as garbage collection in a large heap can be lengthy>.

The best case scenario is a heap 20% larger than the maximum heap from test results. The size should be determined by running a test using the anticipated production system collateral and volume(64bit systems support large heaps which allow for a large Max Inline size if required).

BMC Pool Size

BMC pool size is the other setting which can help in improving the output performance. The default value for “com.adobe.xmlform.bmc.POOL_MAX” is 4. If a server instance has more than four CPU cores, you will get better throughput by setting its value equal to or about 1.5x to 2x the number of CPU cores.

Even though the default POOL_MAX setting is 4, you may not see all four of the XMLForm processes spawned unless the server was hit at any time with four or more concurrent requests. You can verify how many of these processes are running using the following command in Solaris/AIX/Linux:

ps -ef | grep XMLForm

In Windows, you can use Task Manager’s Process tab.

To get all the XMLForm processes spawned and better throughput of output, run your load test with a batch size value higher than POOL_MAX.

A test activity, which showcases the benefits of these parameters was conducted; and it was observed to produce ~300% improvement to give throughput of 2750 Pgs/min as against 980 Pgs/min with default settings.

The settings to get throughput of 2750 Pgs/min were as follows:

For running the tests, configurations were as follows:

  • BMC pool size = 10
  • Watch Folder Batch size = 13
  • Max inline size = 512 KB
  • Input file size(XML) = 490 KB
  • JVM Args: -Xms2048m -Xmx4096m -XX:PermSize=512m -XX:MaxPermSize=1024m

Machine Configuration (on which the tests were run):

  • OS: Win 2008 R2
  • Arch : 64 bit
  • CPU Cores: 8
  • RAM : 32 GB

       ** Results may vary depending upon the hardware spec of the machine, on which tests are performed.

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 6.8/10 (6 votes cast)
Performance Tuning Tips for Faster LiveCycle Output, 6.8 out of 10 based on 6 ratings
This entry was posted in Adobe LiveCycle ES3. Bookmark the permalink.

5 Responses to Performance Tuning Tips for Faster LiveCycle Output

  1. Jack says:

    Do you have recommendations for PDF optimization? The single-threaded nature of Acrobat.exe makes the process of optimizing a large number of documents very slow.

    • swati says:

      Hi Jack,

      You can try configuring POOL Size for GeneratePDFService and DistillerService Configuration under Home -> Services -> Applications and Services -> Service Management.

      Thanks,
      Swati

    • Sudhanshu Singh says:

      Hi Jack,

      As you mentioned – Optimize PDF is dependent on single threaded nature of Acrobat.exe and thus increasing the pool size would not be helpful. For improving the response time of PDF Optimization you can setup a cluster where PDF Optimization requests can be handled by various nodes in parallel.

      Thanks,
      -Sudhanshu

  2. Saurabh Kumar Singh says:

    Hi Jack,
    You are right is saying that bottleneck is single threaded nature of Acrobat. It can’t be scaled, though you can play around with File Type Settings for optimizer to see if the operation can be fasten up.

    @Swati : Thats an incorrect thing Swati. The pool size only configures the pool size on DSC side. I mean the the number of threads of DSC which can process request. However there is a limitation on BMC side that only once BMC for optimizer processes the requests at a time. So even if you have pool size of 100 and 100 requests come in parallel they all will be queued and processed sequentially by BMC.

  3. Hi Jack,
    You are right is saying that bottleneck is single threaded nature of Acrobat. It can’t be scaled, though you can play around with File Type Settings for optimizer to see if the operation can be fasten up. You can also look for doing clustering option to scale. Hardware required for scaling this way should be minimal.

    @Swati : Thats an incorrect thing Swati. The pool size only configures the pool size on DSC side. I mean the the number of threads of DSC which can process request. However there is a limitation on BMC side that only once BMC for optimizer processes the requests at a time. So even if you have pool size of 100 and 100 requests come in parallel they all will be queued and processed sequentially by BMC.