Provisioning a High Performance LiveCycle ES2 Server

One of the most popular blogs by Adobe employees is ‘John Nack on Adobe’ (specializing mostly on Photoshop). John recently posted a blog entry titled “How to set up a great Photoshop machine” which is the inspiration for this blog entry. While Photoshop is typically installed on workstation-class desktop machines, LiveCycle ES2 is typically installed on datacenter-class servers.

We frequently receive questions from Adobe field solutions engineers as well as customers about provisioning hardware for a LiveCycle deployment. For LiveCycle ES2, the following recommendations apply. If you are looking for a base Intel/AMD x64 server platform, the recommendations are the following:
HP Proliant DL 380
Dell PowerEdge 2970
IBM x3650 M3

CPUs
LiveCycle ES2 performance is CPU-bound except in the case of Process Management, which is primarily I/O bound on the database server. This means, you should provision Intel Xeon, AMD Opteron, Oracle SPARC64 VII and IBM POWER 6 CPUs with the highest clock speeds as well as the most cores (within your LiveCycle license limits). Please note, one LiveCycle server CPU license is equivalent to two CPU cores – see policy here. Based on this consideration alone, pure economics makes Intel Xeon-based servers the best in terms of performance:price ratio (biggest bang for your buck).

A sure sign that the CPUs are under-powered is when IBM WebSphere reports the following messages in its SystemOut.log:
CoordinatorCo W HMGR0152W: CPU Starvation detected. Current thread scheduling delay is 76 seconds.
ApplicationMo W DCSV0004W: DCS Stack DefaultCoreGroup at Member aCell01\aNode01\lc1: Did not receive adequate CPU time slice. Last known CPU usage time at 12:31:29:850 EDT. Inactivity duration was 77 seconds.

Memory
Beyond a certain threshold, adding memory is either wasteful, or counter-productive. In ES2, with all LiveCycle components deployed (including Process Management, and Content Services), the heap size requirement comes to about 2-3 GB. Additional non-JVM native components like XMLForm, PDFGen, native application processes etc take up about 100 MB each. Factoring in the requirements for the operating system, additional clients such as backup agents etc, each server instance need only a maximum of 8 GB of RAM. See here for details on tuning memory for LiveCycle ES2.

Disk
Components such as Forms ES2, Output ES2, PDF Generator ES2, and Content Services ES2 create significant temporary disk I/O, primarily to folders designated as the ‘LiveCycle Temporary Folder’. This folder should always be hosted on a local disk or local disk array (not an option in virtualized environments where all storage is remote). The best performant RAID option is a RAID 0 array of multiple disks (block-level striping without parity or mirroring) and should be considered. Please note that RAID 0 does not protect you from even single disk failures. The disks themselves should be SCSI or SAS with platter rotational speeds of at least 10,000 RPM. Solid State Drive (SSD) is also an option. If you have plenty of RAM, RAM disks are another option.

Global Document Storage (GDS)
This is a very important part of LiveCycle. Starting with ES2, you have the option to host it in the LiveCycle database instead of on a network file system. The database option is recommended. Please see here for more on this.

Content Store
If you have licensed Content Services ES2, this folder is criticial as all content gets stored here. There is no option to direct this to the DB. RAID 5 or RAID 6 disk arrays are recommended because they are tolerant of disk failures. If hosted on a SAN (Storage Area Network) or NAS (Network Attached Storage), always choose the best performant tier – IT usually offers 3 tiers of SAN performance.

Storage
See here for details. Each time a service pack is applied (Adobe releases one service pack roughly every quarter for LiveCycle), updated files are backed up. So each service pack will take up an additional 3 GB.

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)
This entry was posted in Adobe LiveCycle ES2 (9.0.x), General Interest and tagged , , , . Bookmark the permalink.

4 Responses to Provisioning a High Performance LiveCycle ES2 Server

  1. Hi Jayan,

    You say in your article “The database option is recommended. “. Is that really true? This article is all about provisioning a high-performance server, yet in your other article, you indicate that there is a performance penalty when using the database. Would you mind clarifying? Are you indicating that, in your opinion, the convenience of using the database outweighs the performance penalty?

    The reason I ask is because we still tend to eschew the database option and use a file system GDS when doing customer installations. The fact that this approach was rejected through the first few LiveCycle releases and the fact that it is not the default approach in Configuration Manager has lead us to conclude that this is really only for customers who explicitly want the convenience more that the performance. Is that wrong?

    Regards,
    Rob

    • Jayan Kandathil says:

      Hi Rob:

      Yes the sheer “convenience of using the database outweighs the performance penalty”.

      • Hi Jayan,
        Is Adobe going to provide some test lab performance statistics for the differences between these 2 GDS configurations? I have had no luck getting this information through Support or Partner channels. We have had to justify each approach in architectural discussions with customers, which is difficult without metrics from the vendor.

        We have gone ahead with Database GDS solutions, and our simple benchmark tests did not show any noticable performance hit. But I’m hoping that Adobe Labs could provide further insight.
        Cheers
        – Duane