LiveCycle – Quick and Dirty Server Sizing

One of the most common problems LiveCycle project sponsors face is determining how many servers they need to deploy to satisfy their throughput and/or SLA (Service Level Agreement) requirements. The following highly generalised information will help in arriving at a ballpark figure for the initial discussion phase:

– LiveCycle performance is CPU-bound in most cases

– The more CPUs your server has, the better transaction throughput you will get

– The better the CPU subsystem (higher clock speeds, higher FSB speeds, better supporting chipsets, faster memory), the better the transaction throughput you will get

– Each server requires at least 4 GB of available RAM. 6 GB will give you a comfortable breathing room. This includes about 1 GB for the operating system, about 2 GB for the java process that hosts the appserver instance, and about 250 MB for LiveCycle’s non-Java components such as XMLForm (which is still 32-bit in ES2). In addition to this, the appserver itself would have other processes running such as the node agent/manager etc.

– As a general rule, LiveCycle can handle roughly 5 concurrent requests on each CPU core. This varies between current Intel, AMD, Sun and IBM processors. For example, if your server has two dual-core CPUs, and if each LiveCycle transaction experiences an elapsed time of 1 second under load, this server can be expected to provide a throughput of 4 cores * 5 concurrent requests * 60 * 60 = 72,000 transactions per hour.

– Your system should be capable of satisfying the SLA at peak concurrent request load

– To determine your peak concurrent request load, consider your absolute busiest hour during your busiest time of the year

– Concurrent requests are NOT the same as the number of users

– Concurrent requests are NOT the same as the number of users currently logged in

– Concurrent requests are requests sent to the server(s) by users or by batch processes that, at any given point in time, are either queued up, or are executing on the server(s). This number is usually a very small subset (2-5%) of the total number of users who are currently logged in to the application

– The LiveCycle database requires about 300 MB of storage at the outset. Storage requirement during production use depends entirely on the custom applications that are built with LiveCycle

– LiveCycle is supported on VMWare ESX, AIX LPARs and Solaris 10 Containers. The same memory requirement (at least 4 GB) applies. Provision at least two CPU cores

– For High Availability (HA), deploy LiveCycle in horizontal clusters of at least two separate servers, physical or logical (like VMWare). Physical is better (provides hardware redundancy)

Please note: Never deploy a LiveCycle-based enterprise application into production use without taking it through the wringer of at least one performance-testing cycle by a competent load testing team with professional-quality tools such as HP LoadRunner, Borland SilkPerformer, IBM Rational Performance Tester, RadView WebLOAD with the Flex 2 Add-On, or Neotys NeoLoad.

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 ES. Bookmark the permalink.

5 Responses to LiveCycle – Quick and Dirty Server Sizing

  1. Kamal says:

    Hello Jayan!I like this. For LiveCycle, This seems to be the only reference material for Hardware sizing.Any thoughts on sizing and clustering for separate BAM and LiveCycle Content Servers?

    • Jayan Kandathil says:


      Please see here for LiveCycle Capacity Planning Guides. Unfortunately, we don’t have any for BAM, or Content Services even in ES2.5

  2. Kamal says:

    And, are there any updates to this on LC ES2 front?

  3. Jayan Kandathil says:

    We’re working on these. Stay tuned.