Purpose

This paper provides a technical overview of the Adobe Intelligent Document Platform for IT professionals and system architects working in the enterprise environment. It explains the factors that such professionals will need to take into consideration when planning a network, including how to calculate processing capacity and usage requirements, as well as how to manage the applications for the most efficient use of your resources.

Executive summary
The Adobe Intelligent Document Platform allows enterprises to replace inefficient, manual, paper-based processes with streamlined, automated processes that extend to employees, customers and partners, in and outside the firewall. Within the Intelligent Document Platform framework, the LiveCycle suite of components provides advanced process management and security functionality. IT architects who are implementing Adobe LiveCycle software can leverage its flexibility to maximize performance during the design, deployment and ongoing maintenance phases. This paper provides guidelines for the design and deployment of the server architecture. It describes how to calculate usage patterns and processing capabilities, as well as how to manage response times for specific applications. Recommendations for managing applications and control processes are also included. Understanding the resource usage and performance requirements of the Adobe Intelligent Document Platform and LiveCycle software components allows you to design high performance solutions that maximize resource usage of your IT infrastructure and plan for future growth.

Background
In todays business environment, people need to interact with data stored in enterprise applications. As the need to interact with data stored in enterprise applications expands beyond the core users, adapting systems to meet this need has become an expensive and time-consuming endeavor. The result is a proliferation of manual workarounds that result in process inefficiencies, delays, and poor quality of information. By combining the business logic and data exchange capabilities of XML with the visual fidelity, security, and reliability of Adobe PDF, Adobe LiveCycle makes it easy for companies and government agencies to convert static documents into electronic ones, 3

then integrate them with the existing enterprise applications and business processes. Ultimately, this helps organizations streamline information exchange among employees, suppliers, customers, and constituents; increase operational efficiencies; reduce costs; and meet compliance mandates. Increased adoption rates occur over time, with promotional campaigns and as users become more familiar with the system. This will lead to an increase in the number of users and an increase in system traffic. In addition to increases in system traffic, IT architects must also consider the increased expectations of users within the enterprises computing environment. Research indicates that users on average will wait between four and eight seconds for an online page display. For these reasons, it is critical to use network resources as efficiently as possible while having the ability to meet the demand when it increases. This paper discusses performance and resource-usage considerations critical to a platforms successful design, operations and maintenance in an enterprise, computing environment. **Are there other problems unique to an enterprise environment that we should mention here? What about the need for open source?

The Adobe Solution

The Adobe Intelligent Document Platform provides a secure and flexible way to extend the power and reach of enterprise applications inside and outside the firewall. The platform leverages Adobe Document Services to create Intelligent Documents and integrate them into business processes. It empowers enterprises to replace inefficient, manual, paper-based processes with streamlined, automated processes that include customers, partners, and employees. The platform supports Adobe LiveCycle software and works with commonly used web browsers and Adobe Reader. Adobe LiveCycle software is a new generation of server products and design tools built on the common Java 2 Platform, Enterprise Edition (J2EE) architecture.The Adobe Intelligent Document Platform integrates easily with common J2EE server architectures in existing IT infrastructures. It builds on commonly used technologies such as LDAP directories, application servers, mail servers, XML, SOAP, Java APIs and universally deployed clients. The Adobe LiveCycle suite of products includes the following software: Adobe LiveCycle Forms does X. Adobe LiveCycle Reader Extension software allows you to provide the functionality of Acrobat Reader to users who do not have Adobe Acrobat, and add usage rights to PDF documents.. Adobe LiveCycle Form Manager does X. Adobe LiveCycle Document Security automates encryption, certification and digital signatures of electronic documents. Adobe LiveCycle Designer is a client-side application that does X.

This paper focuses on server applications only; for information about client-side applications, see X. See Deploying Adobe LiveCycle in the Enterprise Environment for detailed information about product-specific deployment requirements. **what information exists for the customer on this topic? The Adobe Intelligent Document Platform is flexible and scalable, so you can design and build the system you need for todays user requirements. As user adoption increases, you can scale the system to accommodate future growth. This allows you to maximize current IT investments today and plan new investments based on the enterprises usage patterns and needs. To maximize the performance of these products, you need to understand the following: Usage patterns the maximum number of concurrent users who access the system at a given time represents the peak volume of traffic. The platform must be robust enough to provide users similar response times, regardless of network traffic. Processing capabilitiesdetermine the processing capacity of your network based on the complexity of the HTML pages, PDF forms, and pages to be rendered. Application response times providing an acceptable response time for page displays in the users browsers is a critical, success factor Application management and control processes determine additional functionality needed to control internal handling and processing

Calculating usage patterns

Review network traffic patterns and estimate the maximum number of users who will access the system at any given time to define peak traffic periods. Ensure there is sufficient processing power to handle the maximum number of concurrent users. The base number of CPUs you deploy will depend on the usage patterns you expect. This can be difficult to assess; however, the two key factors to consider when determining usage patterns are the estimated number of users and the frequency of use or currency ratio.

Estimating users and frequency ratios

The number of users is the actual maximum number of users who will make requests to LiveCycle Forms on a daily basis. While thousands of users may potentially be using the system, the IT architect needs to assess how many of these potential users will actually make requests to the LiveCycle Forms component each day. This requires doing an initial estimate, and monitoring the usage once the application is deployed to determine if more servers are required. 5

J2EE Application Servers generally handle volumes of requests by queuing them on a first-come, first-served basis. The server manages the number of configured users based on the number of process pools (see Using process pooling). The frequency or concurrency ratio represents the number of users who will request a form in a one-second period. For example, a 100:1 ratio means that 1 out of 100 users will request a form within the same one-second time span. With this ratio, for every 1,000 users, 10 will request a form in a one-second time span. Table 3 provides guidelines for estimating the concurrency ratio, based on the number of form requests per user, per day. Frequency Ratio (n:1) 125:1 100:1 75:1 50:1 Custom Form Requests Per User Per Day 1 to 4 5 to 10 10 to15 15 to 20 20 or more

Table 3: Estimating the concurrency ratio **As a reader, I stumbled over this table a bit. Would it make sense to reverse the order of the columns so that the form requests are on the left side---then readers would be determining the ratio from the number of form requests? LiveCycle Forms is architected to handle the number of concurrent requests defined by the process pools. If more concurrent transactions are submitted, LiveCycle services simultaneously processes the number allocated by the pools, and queues the overflow for sequential processing as the queue clears.

Addressing peak volumes

Adobe Systems recommends designing your architecture to handle the peak volume of requests. When estimating the CPUs required for your platform, it is important to understand the peak volume spikes that occur each day. The CPU may be shared among users that send requests at the exact same time to handle peak volumes. Daily, peak volumes of transactions are monitored on an ongoing basis to determine if additional servers are needed to provide the required response time. You will need to plan for exceptional usage days. Most applications will experience extremely heavy traffic occasionally, often due to business activities or promotions. It may not be cost-effective or possible to increase server capacity for short bursts of traffic, but it may be acceptable to allow response times to degrade on these occasional days.

In general, the performance requirement is to render the forms with a response time that is under the maximum threshold of four seconds or that users will tolerate. Figure 1 shows the expected traffic patterns for a sample application. It includes the expected transformation requests from users, the amount of expected wait time, and an optimized solution with a maximum wait time per user of four seconds (the red triangle line).
14 12 10 Seconds 8 6 4 2 0 Time Transformation Requests Wait Time in secs. Maximum Wait Time

Figure 1: Analyzing peak volume In the diagram, the purple square line represents the wait time based on number of requests for forms and the blue diamond line represents the request for forms. During the business day, two volume peaks occur where requests for forms are high. If the solution is created for peak volume times, the wait time for users is always under the four second maximum threshold. In this case, the response time at peak periods is a maximum of four seconds. No additional CPUs are needed because the system can handle the load at peak periods and still deliver within the maximum expected wait time. If the wait time during peak periods in the diagram is eight seconds, then the number of CPUs needs to be adjusted to ensure that the TPS at peak periods is maintained under the four second requirement. To handle the peak periods in this case, twice as many CPUs are required to maintain four transactions per second instead of eight. Adobe LiveCycle Forms handle concurrent users and concurrent requests differently. LiveCycle Forms can support many users simultaneously because it neither retains a state nor provides a concurrent session for each user. The application determines this by comparing the number of simultaneous users with the number of concurrent requests coming to the server. With stateless and session-less applications, the only time a concurrent request causes concern is when users issue requests that cause LiveCycle Forms to actually render concurrently. You can assess this by monitoring concurrent requests.

You can add a counter to the calls-to-APIs to determine if there are patterns for concurrent requests over time. Some customers assign a value between 2 % and 5 % for concurrent requests, compared to concurrent users. This accounts for the time users need to think, while they enter data in form fields and click buttons that initiate new page-view renderings.

Calculating processing capabilities

To determine the processing capabilities need in your network, you must compare throughput requirements for the solution with the capabilities of your current server infrastructure. As users adoption rates increase, you will need to scale the solution to meet the expected increase in demands. Adobes Performance Labs can provide performance benchmarks and recommended configurations. Because of the variation among enterprise solutions, these benchmarks should be used as comparisons only. Calculate throughput measurements using actual form designs that will be deployed on your platform. Compare the throughput requirements with the throughput capabilities of the deployed servers. Analyze the currently deployed CPUs to determine how they compare to the CPUs used in Adobes performance-benchmark tests. Sidebar: The throughput calculation for LiveCycle Forms assumes that no other application is running on the same application server with the LiveCycle software.

CPU capabilities
The systems CPU determines maximum throughput capabilities and drives sizing requirements for LiveCycle Forms. It does not matter how many concurrent users you add to the servers, the throughput will peak when the CPU reaches its maximum. Table 1 lists the performance benchmarks for supported platforms, tested in Adobes Performance Labs. Determine the CPU capability of your infrastructure using the benchmark CPU ratings in the table. The different components are benchmarked on the platforms using a minimum of 64Mb RAM. The CPU ratings were derived from the Standard Performance Evaluation Corporations (SPEC) CPU benchmarks, used to compare different servers. SPEC, www.spec.org, is a nonprofit corporation formed to establish, maintain and endorse a standardized set of relevant benchmarks that can be applied to the newest generation of high-performance computers. It develops suites of benchmarks, reviews and publishes submitted results. System Windows 2003/ Linux RedHat AS2.4 8 CPU Rating 28.1

Dell Precision 650 3.2 GHz Dual AIX 5.2 IBM 7029-6C3 1.2 GHz Dual Solaris 9 Sun SunFire v210 UltraSPARC IIIi 1.0 GHz Dual Table 1: CPU benchmarks

http://www.spec.org/cpu2000/results/res2004q1/cpu2000-2004012602799.pdf

15.2
http://www.spec.org/cpu2000/results/res2003q2/cpu2000-2003052702200.pdf

10.2
http://www.specbench.org/osg/cpu2000/results/res2003q2/cpu200020030331-02013.html

Sidebar: Adobe Systems provides minimum system configuration requirements for supported platforms. Contact your Adobe representative if you need these values to assess preliminary or temporary sizing requirements for your solution.

Calculating throughput requirements

Throughput is measured by calculating transactions per second (TPS).

Calculating transactions per second

Calculate throughput using the actual forms that will be deployed in your solution to obtain accurate results. Adobe can provide TPS measurements for different types of forms; however, you should use this data for comparative analyses only. Adobe has developed tools that render XDP form designs in HTML and PDF formats as many times as possible over a specified period of time. Monitor CPU usage during testing. If the CPU usage does not reach 100%, your servers will be able to handle more requests. You must use multiple concurrent requests to achieve a higher TPS value. At least eight concurrent users were required to achieve maximum TPS values in Adobe Performance Labs. To calculate TPS, invert the average result of your throughput tests. Sidebar: Adobe Systems has calculated a series of throughput values for supported platforms and simple, normal and complex forms. Please contact an Adobe representative for values you can use to assess preliminary and temporary sizing requirements for your LiveCycle solution.

TPS = Transactions / (Seconds * CPUs)

For example, a fifteen minute (900 second) test is run using a simple form on a two-CPU server, with eight concurrent users submitting requests. During this period, 18,000 transactions were processed, indicating 10 transactions per second are possible.
TPS = 18,000 / (900 * 2) = 10

The complexity of the forms you use will impact throughput. To achieve more accurate results, use a weighted calculation based on the complexity of your forms. Simple, normal, and complex forms and are defined by the number of pages and objects they contain. Form Type Simple Normal Complex Table 2: Form complexity To perform a weighted calculation, multiply the TPS results obtained for each form type by the percentage of the total number of forms deployed, and add the results. Description Single page forms with less than 50 objects and few server-side scripts Two page forms containing between 50 to 100 objects per page, and some server-side scripts Multiple page forms containing 100 or more objects per page and several server side scripts

Simple forms: Normal forms:

aa=% of total forms bb=% of total forms

Complex forms: cc=% of total forms TPS = (TPSSimple * aa) + (TPSNormal * bb) + (TPSComplex * cc)

Form types and page complexity Page complexity varies among types of forms and affects performance. Complexity is determined by the number of objects in the forms, whether the forms are static or interactive, and rendered in PDF or HTML. Throughput varies between static and interactive PDF forms and HTML forms. If your solution uses a mixture of form types, you need to calculate the different transformations separately. Multiply the calculation of each form-type by the percentage it will be used. 10

For example, if 80% of the transformations will be to HTML and PDF transformations will account for 20%, use the following formula:

HTML_TPS = TPSSimple * aa + TPSNormal * bb + TPSComplex * cc PDF_TPS = TPSSimple * aa + TPSNormal * bb + TPSComplex * cc TPS = HTML_TPS * 0.80 + PDF_TPS * 0.20

The calculations also depend on the servers used to perform the tests. If they are the same as those that will be used in the production environment, then no adjustment is required. However, if the test and production servers are different, adjust the TPS using the appropriate SPEC values for the servers used in the production environment (CPUSpecPD). The value, CPUSpecLb, is the value for the servers used for the TPS benchmark tests in Adobe Performance Labs. Because the product is primarily CPU bound, you can normalize the target response time on each server using the CINT2000 rates provided for the servers. Sidebar: Refer to www.spec.org for the CPU CINT2000 Rates for the server.

adjustTPS = TPS * CPUSpecPd / CPUSpecLb

The CPU capacity is the main factor that affects performance and is used to size and scale the LiveCycle platform. Adobe LiveCycle Forms APIs are atomic. They are session-less and stateless; therefore, any server can process any request and provide platform redundancy. Use load balancing to ensure the system is always running. At least one server should be up at all times if you install two servers, even during upgrades and other maintenance activities. For long term growth and operations and maintenance guidelines, see Scaling the Adobe Intelligent Document Platform.

Vertical scalability
A single LiveCycle Forms CPU supports 750 to 1500 users a day. Additional CPUs need to be added to support expected increases in the numbers of users. 11

Tests were performed to determine the peak throughput possible based on a variable number of CPUs. The efficiency factor was measured when scaling from 2 to 4 CPUs, from 2 to 8 CPUs and from 4 to 8 CPUs. Preliminary benchmark testing indicates that you can expect a loss of between 10 and 15% in efficiency per CPU when scaling from 2 to 8, or 4 to 8 CPUs. CPU comparison 2 to 4 CPUs 2 to 8 CPUs 4 to 8 CPUs Efficiency Factor 0.96 0.84 0.88

Table 5: Efficiency factor when scaling up (number of CPUs)

Load balancing
The Adobe Intelligent Document Platform uses the Application Server to support software and hardware load balancing. Load balancing maximizes the use of existing resources. LiveCycle Forms and Form Manager are designed to be stateless and session-less. A stateless service does not maintain application, session or user information after processing a transaction. This eliminates the need to have a one-to-one session with the end user or the application, and allows organizations to deploy additional servers in a one-to-many or a many-to-many environment.

12