ADS Sizing Guide

Sizing Guide

Sizing for Adobe Document Services Interactive Forms based on Adobe Software (SAP NetWeaver ‘04 SPS18 or higher

SAP NetWeaver 2004s SPS05 or higher)

Released for SAP Customers and Partners

Document Version 2.1 - August, 2006

Released for SAP Customers and Partners

© Copyright 2006 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation in the United States and/or other countries. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. Disclaimer Some components of this product are based on Java™. Any code change in these components may cause unpredictable and severe malfunctions and is therefore expressively prohibited, as is any decompilation of these components. SAP Library document classification: CUSTOMERS & PARTNERS Documentation in the SAP Service Marketplace You can find this documentation at the following address: http://service.sap.com/sizing

© SAP AG / Adobe Systems Released for SAP Customers and Partners 2

© 2006 Adobe Systems Incorporated. All rights reserved. Sizing Adobe® Document Services, Release 2.7 March 2006

If this guide is distributed with software that includes an end user agreement, this guide, as well as the software described in it, is furnished under license and may be used or copied only in accordance with the terms of such license. Except as permitted by any such license, no part of this guide may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, recording, or otherwise, without the prior written permission of Adobe Systems Incorporated. Please note that the content in this guide is protected under copyright law even if it is not distributed with software that includes an end user license agreement.

The content of this guide is furnished for informational use only, is subject to change without notice, and should not be construed as a commitment by Adobe Systems Incorporated. Adobe Systems Incorporated assumes no responsibility or liability for any errors or inaccuracies that may appear in the informational content contained in this guide.

Please remember that existing artwork or images that you may want to include in your project may be protected under copyright law. The unauthorized incorporation of such material into your new work could be a violation of the rights of the copyright owner. Please be sure to obtain any permission required from the copyright owner.

Any references to company names and company logos in sample material or in the sample forms included in this software are for demonstration purposes only and are not intended to refer to any actual organization.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries.

SAP, ABAP, SAP NetWeaver, and xApps are trademarks or registered trademarks of SAP AG in Germany and in several other countries.

All other trademarks are the property of their respective owners.

Adobe Systems Incorporated, 345 Park Avenue, San Jose, California 95110, USA.

Notice to U.S. Government End Users. The Software and Documentation are “Commercial Items,” as that term is defined at 48 C.F.R. §2.101, consisting of “Commercial Computer Software” and “Commercial Computer Software Documentation,” as such terms are used in 48 C.F.R. §12.212 or 48 C.F.R. §227.7202, as applicable. Consistent with 48 C.F.R. §12.212 or 48 C.F.R. §§227.7202-1 through 227.7202-4, as applicable, the Commercial Computer Software and Commercial Computer Software Documentation are being licensed to U.S. Government end users (a) only as Commercial Items and (b) with only those rights as are granted to all other end users pursuant to the terms and

conditions herein. Unpublished-rights reserved under the copyright laws of the United States. Adobe Systems Incorporated, 345 Park Avenue, San Jose, CA 95110-2704, USA. For U.S. Government End Users, Adobe agrees to comply with all applicable equal opportunity laws including, if appropriate, the provisions of Executive Order 11246, as amended, Section 402 of the Vietnam Era Veterans Readjustment Assistance Act of 1974 (38 USC 4212), and Section 503 of the Rehabilitation Act of 1973, as amended, and the regulations at 41 CFR Parts 60-1 through 60-60, 60-250, and 60-741. The affirmative action clause and regulations contained in the preceding sentence shall be incorporated by reference.

© SAP AG / Adobe Systems Released for SAP Customers and Partners 3

TABLE OF CONTENTS

1 INTRODUCTION..........................................................................................................................................5 1.1 FUNCTIONS OF ADOBE DOCUMENT SERVICES...........................................................................................5 1.2 ARCHITECTURE OF ADOBE DOCUMENT SERVICES ....................................................................................5 1.3 FACTORS THAT INFLUENCE PERFORMANCE..............................................................................................6 1.4 RESULTS FROM PERFORMANCE TEST ........................................................................................................7

2 PERFORMANCE TEST FOR PRINT FORM SIZING FOR ADOBE DOCUMENT SERVICES.......7 2.1 ASSUMPTIONS FOR SIZING ........................................................................................................................7 2.2 DETERMINING SAPS RATING FOR EACH DOCUMENT TYPE......................................................................7 2.3 SIZING GUIDELINE.....................................................................................................................................9

3 BATCH PRINT SIZING FOR ADOBE DOCUMENT SERVICES .......................................................11 3.1 ASSUMPTIONS .........................................................................................................................................11 3.2 DETERMINING SAPS RATING FOR EACH DOCUMENT TYPE....................................................................11 3.3 SIZING GUIDELINE...................................................................................................................................13

4 INTERACTIVE FORM SIZING FOR ADOBE DOCUMENT SERVICES..........................................15 4.1 ASSUMPTIONS FOR SIZING ......................................................................................................................16 4.2 DETERMINING SAPS RATING FOR EACH DOCUMENT TYPE....................................................................16 4.3 SIZING GUIDELINES.................................................................................................................................18 4.4 INTERACTIVE FORM SIZING EXAMPLE ....................................................................................................19

5 APPENDIX A – PRINT FORM SAMPLE ................................................................................................20 6 APPENDIX B – INTERACTIVE FORM SAMPLES...............................................................................21 7 APPENDIX C –BATCH PRINT FORM SAMPLES................................................................................24

© SAP AG / Adobe Systems Sizing Adobe Document Services 4

SAP Customers and Partners

1 Introduction This document is intended for SAP performance analysts and customers as a general guide to determining server size requirements for the Adobe document services component in their particular installations. This document will provide size guidance based on generic server requirements such as size of documents and data as opposed to end-user business cases.

Adobe document services render PDF, PCL, PostScript, and other output formats from form designs created using the Adobe LiveCycle Designer. Section 2 of this document is primarily concerned with the production of print output (PCL and Postscript) when called in batch or “print” mode. Section 3 is primarily concerned with the production and modification of interactive PDF when called in single request or “interactive” mode.

This document applies to following releases:

• SAP NetWeaver ‘04 SPS18 and later

• SAP NetWeaver 2004s SPS05 and later.

An earlier version of this document is available for the following releases:

• SAP NetWeaver ’04 before SPS18

• SAP NetWeaver 2004s before SPS05

You find these documents on the SAP Service Marketplace under http://service.sap.com/adobe → Media Library → Documentation

1.1 Functions of Adobe Document Services For print, Adobe document services will be called in batches to produce PCL and PostScript. The output is written to a spool file, which is then output to a printer. A batch consists of a form design created using LiveCycle Designer and a data file with multiple data records. When Adobe document services merge the form design and the multi-record XML data, documents in PCL or PostScript format that contain the results of all the records in the batch are created and returned to the calling application. The resultant output from Adobe document services is written to a spool file and output to a printer.

In interactive mode, Adobe document services are called (for the scope of this document) to produce a single interactive PDF. The contents of an interactive request are similar to those of a print request except that the data file contains a single record, thus producing a single output file. Security settings may be applied to the generated PDF before it is returned to the calling application. The security settings define how the PDF can be modified and printed by the viewer. Interactive PDFs are generally created as part of an application workflow.

1.2 Architecture of Adobe Document Services The form processing run time in the ABAP Workbench stack makes use of a PDF object to call Adobe document services. Adobe document services are passed a form design and data, and then calls the XML form component to merge the form design and multiple data records to produce the PCL or PostScript output. The resultant documents are returned to the form processing run time, which then passes the output to the post-processing framework. The post-processing framework writes the output to the spooler. The spooler then transmits the output to the printer.

In interactive mode, the form design is merged with a single data record to produce the PDF, which is then returned to the calling application in the workflow.



http://service.sap.com/adobe

.

1.3 Factors That Influence Performance The following factors influence performance (more specific factors can be found in sections 2 and 3):

• Size and complexity of the form design. The size of the form design is determined by the number of elements on the form design. A form design may consist of any number of pages.

• In print mode, the amount of scripting that is in the form design. Interactive forms generally contain little server-side scripting, thus having little affect.

• In print mode, the number of records in the data file to be merged. This defines the batch size where each data record corresponds to a single piece of output.

• Amount of data in each record; that is, the number of pages of generated output.

• Number of parallel requests being processed.

• Size of the output that the batches generate. Entire output is returned in a memory buffer.



1.4 Results from Performance Test The result of this document will be a sizing estimate for the target server based on the input provided. For standardization, this measure is expressed in “SAPS”.

SAPS is a hardware independent unit used to describe the CPU-related performance characteristic of a given hardware configuration. For additional information on SAPS and their equivalent hardware performance, see www.sap.com/benchmark -> SAPS.

The performance tests were performed with Adobe document services in SAP Web Application Server 6.40 SP14 on a dual CPU Intel 3.4GHz Xeon-based server with a rating of approximately 3000 SAPS.

The SAP NetWeaver ‘04 system needs to be sized so that it can handle the worst case load at 66% CPU utilization.

2 Performance Test for Print Form Sizing for Adobe Document Services

Print form sizing will depend on the complexity of the form designs that are given to Adobe document services to render. It is assumed that a given application will be a mixture of simple, medium, large, and extra-large forms. The flight data form was selected from the SAP performance test samples to represent each of the four types of complexity. (See Appendix A for a sample of this form.)

Performance tests were run to determine the sizing using flight data forms with 1, 10, 100, and 1000 pages. The definition was as follows: Small: equivalent to 1 page of flight data. Medium: equivalent 10 pages of flight data. Large: equivalent to 100 pages of flight data. Extra-large: equivalent to 1000 pages of flight data.

2.1 Assumptions for Sizing Adobe document services will be called in small batches that reduce the communication and

invocation overhead. It will be assumed that parallel requests can be made to fully utilize the CPU. Adobe document services can be called by either passing the request files by way of streams or

URI (that is, HTTP URL or local file system). By default, the form design is passed by URl and the data by way of a stream.

It is assumed that Adobe document services are called in such a way that they can be scaled linearly, horizontally, and vertically.

It is also assumed that Adobe document services will run proportionally the same speed on various platforms based on the CPU rating of the hardware.

The ABAP Workbench stack and Adobe document services exist on the same hardware device for optimal configuration.

2.2 Determining SAPS Rating For Each Document Type This section describes how a performance test was constructed to determine the SAPS rating for each Adobe document services print document complexity type. These SAPS ratings can then be reused for each customer business case.

The criteria for determining the complexity of a form will be the number of form elements, the amount of script, and the size of the data. The flight data forms were chosen from SAP samples to represent each of four form types: small (1-page), medium (10-page), large (100-page), extra-large (1000-page).



http://www.sap.com/benchmark

The performance test was performed as follows:

Using an optimal size of batches, the maximum throughput of the flight data form in pages per hour was determined.

• Let cpu_saps be the SAPS rating of the CPU performing the performance test.

• Let sph be the number of small print documents that can be generated per hour.

• Let mph be the number of medium print documents that can be generated per hour.

• Let lph be the number of large print documents that can be generated per hour.

• Let eph be the number of extra-large print documents that can be generated per hour.

Example 1: Performance Test Results

cpu_saps = 3000 SAPS (SAPS rating of the computer performing the benchmark)

• sph = 25200.0 (small documents per hour)

• mph = 4320.0 (medium documents per hour)

• lph = 720.0 (large document per hour)

The system needs to be sized so that it can handle the worst case load at 66% CPU utilization. These results have been scaled to 66% CPU utilization.

The SAPS rating of each print form complexity were determined as follows:

• SAPS(small per hour) = cpu_saps / sph = .1190 SAPS

• SAPS(medium per hour) = cpu_saps / mph = .6944 SAPS

• SAPS(large per hour) = cpu_saps / lph = 4.1667 SAPS



2.3 Sizing guideline For a printing application, the SAPS rating is determined based on the number of small, medium, and large that the calling application is expected to produce per hour.

The documents that the application produces must be compared with the SAP flight data sample Adobe document services documents (Appendix A) that have been benchmarked in section 2.2.

With this SAPS rating for each document type, we can estimate the total number of SAPS required for an application with the following formulas.

Small

SAPS = small documents required per hour * SAPS (small per hour)

= small documents required per hour * 0.1190

Medium

SAPS = medium documents required per hour * SAPS (medium per hour)

= medium documents required per hour * 0.6944

Large

SAPS = large documents required per hour * SAPS (large per hour)

= large documents required per hour * 4.1667

The Total SAPS can then be converted to a number of computers by dividing the total SAPS required by the SAPS rating of the computer being considered to run the application. (See www.sap.com/benchmark to determine the SAPS rating of the computer considered for the application.)

#of computers = Total SAPS / machine_saps

The memory usage will depend on the size of the batch output; however, it is assumed that the batch sizes will be small enough that a simple guideline of allocating 1GB of RAM per CPU is sufficient.




Example 2:

This example uses the SAPS ratings calculated in Example 1 (see section 2.2).

The customer requires 10000 small documents per hour, 12500 medium documents per hour and 300 large documents per hour.

The customer is using a 4-way SMP computer with, according to www.sap.com/benchmark, a SAPS rating of 4700.

• SAPS required for small documents = 10000 * 0.1190 = 1190 SAPS

• SAPS required for medium documents = 12500 * 0.6944 = 8680 SAPS

• SAPS required for large documents = 300 * 4.1667 = 1250 SAPS

This application can be represented in a table (shown below).

The total number of SAPS that Adobe document services require can be determined by summing the SAPS ADS Server column.

Category Up to # documents per hour SAPS ADS server

Small 10000 1190

Medium 12500 8960

Large 300 1250

Total SAPS 11400

The customer would require 11400 / 4700 = CPU power equivalent to approximately three 4-way SMP computers as described above.




3 Batch Print Sizing for Adobe Document Services When printing individual documents, there is a fixed amount of overhead per document processed. When the documents are small, this overhead can become a disproportionate fraction of the total time taken for the job. One way to overcome this is to print small jobs in batches. In this way, the fixed overhead for a job is shared over many jobs, reducing the total processing time. In many cases this improvement can be very significant.

The server sizing for batch printing will depend on the complexity of the form designs that are given to Adobe document services to render. There are two different types of batch printing: Homogeneous Batch Printing – Using multiple data sources and one template, multiple outputs

are produced (PDF, PCL, ZPL, PS…) Heterogeneous Batch Printing – Using multiple data sources and multiple templates, multiple

outputs are produced (PDF, PCL, ZPL, PS...).

It is assumed that a given application will be a mixture of small, medium, and large forms. The different forms were selected from the SAP performance test samples to represent each of the three types of complexity. (See Appendix C for a sample of this form.)

Tests were run to determine the performance of the different forms, having 1, 2 and 4 pages, in homogeneous batch printing mode. For the performance test, a form’s size will be defined as follows: Small: equivalent to 1 page of data Medium: equivalent 2 pages of data Large: equivalent to 4 pages of data.

3.1 Assumptions Adobe document services will be called in batches of 50 documents using homogeneous batch

printing. It will be assumed that parallel requests can be made to fully utilize the CPU. Adobe document services can be called either by passing the request files by way of streams or

by URI (that is, HTTP URL or local file system). By default, the form design is passed by URl and the data by way of a stream.

It is assumed that Adobe document services are called in such a way that they can be scaled linearly, horizontally, and vertically.

It is also assumed that Adobe document services will run proportionally the same speed on various platforms based on the CPU rating of the hardware.

The ABAP Workbench stack and Adobe document services exist on the same hardware device for optimal configuration.

3.2 Determining SAPS Rating For Each Document Type This section describes how a performance test was constructed to determine the SAPS rating for each Adobe document services print document complexity type when using batch printing. These SAPS ratings can then be reused for each customer business case.

The criteria for determining the complexity of a form will be the number of form elements, the amount of script, and the size of the data. The following forms were chosen to represent each of the three types.

• Illness and Injury Report for OSHA – small (1 page).

• Check Deposit Status Report - medium (2 page).

• Customer Account Statement – large (4 page).




Using a batch sizing of 50, the maximum throughput of the forms in pages per hour was determined (number of transactions/sec * 3600 * 50[batch size]).


• Let sph be the number of small print documents that can be generated per hour.

• Let mph be the number of medium print documents that can be generated per hour.

• Let lph be the number of large print documents that can be generated per hour.


cpu_saps = 3000 SAPS (SAPS rating of the computer performing the performance test)

• sph = 54000 (small documents per hour)

• mph = 24300.0 (medium documents per hour)

• lph = 1800.0 (large document per hour)

The system needs to be sized so that it can handle the worst-case load at 66% CPU utilization. These results have been scaled to 66% CPU utilization.

The SAPS rating of each print form complexity were determined as follows:

• SAPS(small per hour) = cpu_saps / sph = .0556 SAPS

• SAPS(medium per hour) = cpu_saps / mph = .1234 SAPS

• SAPS(large per hour) = cpu_saps / lph = 1.6667 SAPS



3.3 Sizing guideline For a printing application, the SAPS rating is determined based on the number of small, medium, and large documents that the calling application is expected to produce, per hour, in batch printing mode.

The documents that the application produces must be compared with the different Adobe document services documents (Appendix C) that have been benchmarked in section 4.2.

With this SAPS rating for each document type, we can estimate the total number of SAPS required for an application with the following formulas.

Small

SAPS = small documents required per hour * SAPS (small per hour)

= small documents required per hour * 0.0556

Medium

SAPS = medium documents required per hour * SAPS (medium per hour)

= medium documents required per hour * 0.1234

Large

SAPS = large documents required per hour * SAPS (large per hour)

= large documents required per hour * 1.6667

The total SAPS can then be converted to a number of computers by dividing the total SAPS required by the SAPS rating of the computer being considered to run the application. (See www.sap.com/benchmark to determine the SAPS rating of the computer considered for the application.)

#of computers = Total SAPS / machine_saps

The memory usage will depend on the size of the batch output. However, it is assumed that the batch size of 50 that was used in the performance test will be enough that a simple guideline of allocating 1GB of RAM per CPU is sufficient.




Example 4:

This example uses the SAPS ratings calculated in Example 3 (see section 3.2).

The customer requires 10000 small documents per hour, 12500 medium documents per hour, and 300 large documents per hour to be printed using batch printing.


• SAPS required for small documents = 10000 * 0.0556 = 556 SAPS

• SAPS required for medium documents = 12500 * 0.1234 = 1542 SAPS

• SAPS required for large documents = 300 * 1.6667 = 500 SAPS


The total number of SAPS that Adobe document services require can be determined by summing the SAPS ADS Server column.


Small 10000 556

Medium 12500 1542

Large 300 500

Total SAPS 2598

The customer would require 2598 / 4700 = CPU power equivalent to approximately one 4-way SMP computers as described above.




4 Interactive Form Sizing for Adobe Document Services In a typical application workflow, interactive forms are used to gather specific information and approvals throughout an organization. For example, an employee fills out an online requisition for a new monitor. This form is submitted to the SAP server which, after applying business rules to the form, sends it to the employee’s manager. The manager reviews the form and approves the item for purchase. The form is again submitted to the SAP server, and the cycle continues until the form has traveled through each point in the workflow.

Before the form reaches the employee, it must be rendered by Adobe document services. During form generation, Adobe document services produce an interactive PDF and apply security settings before the form is returned to the calling application. Specific security settings are defined in the form generation request. They define how the form may be modified (such as fill and sign, modify annotations, and so on), printed (that is, high/low quality or not at all), and whether form content can be extracted.

In addition to the security settings, Reader usage rights, that define whether certain Adobe Reader functionality is exposed while the form is displayed, are also available. For example, the ability to import and export the form contents in Adobe Reader can be made available or hidden by defining the associated Reader usage right.

Part of the client-side form interaction involves the use of digital signatures. This provides an approval mechanism to validate a form’s state at a given point in the application workflow. The employee’s manager in the above example would use a digital signature to show that the monitor purchase is approved. The manager has a credential that identifies that person. A credential consists of two parts: a private key used to sign documents and a public key used to verify the signature. The private key is closely guarded, but the public key is distributed to each entity that needs to verify that manager’s signature. When a form is signed, a snapshot of the form state is preserved so that it can be retrieved later.

When the server receives a signed form, a list of signatures is typically retrieved and each signature is validated to ensure the form is in good standing. When the form’s standing is established, a request is sent to Adobe document services to retrieve the form state when a given signature was applied. The form state includes the values for each form field at the time of signing. The server business logic may retrieve two or more states to compare certain values as part of the form’s approval process. If the monitor quantity in our example changed between signatures, it could be considered a reason to question the form’s approval.

Adobe document services form generation offers a PDF caching mechanism when outputting cacheable interactive PDFs. A version of the form (without data) is stored and later retrieved when subsequent requests for the same form are received. Data for each of the subsequent requests is merged into the cached PDF and returned to the calling application. If the same Reader usage rights are always applied to the same interactive form, they can also be cached, thus realizing an additional performance gain.

Interactive forms tend to have a static data format (not the actual values) and page count from one instance of a form to the next. In contrast, print forms generate output until the entire data file contents are processed. There is no need to regenerate the base form for each instance of an interactive form when only the field values themselves change.

In a typical SAP-based application workflow, the following steps are performed:

1. The user logs into an interactive form-based application and requests a specific form.

2. A request is sent to Adobe document services to generate an instance of that form and to apply a set of Reader usage rights, and then the form is sent to the user.

3. When completed, XML data is sent to the server for processing.

Steps 2 and 3 may repeat several times within the workflow.

4. A final review copy of the form is presented to the user.

5. The system extracts the final form data and validates the digital signatures.



Interactive form sizing is more complex than print form sizing due to the nature of interactive forms. Print forms inherently contain repeating data and are sized based on the amount of space required to represent that data.

Interactive forms are generally limited to a small number of pages and therefore require multiple forms to properly determine sizing. Forms with one, two, and fours pages are used for the interactive form size testing.

For the performance test, four forms will be used consisting of two one-page forms (simple and complex), one two-page form, and one four-page form. Interactive form complexity is based on the number of pages, number of interactive form elements (such as drop-down lists and texts fields), and the number of static form elements (such as text and graphics). Almost all interactive form scripting is performed on the client and rarely affects the form generation time on the server.

4.1 Assumptions for Sizing • Adobe document services will be called as single requests to perform one or more operations per

request. It is assumed that parallel requests can be made to fully utilize the CPU(s). • Adobe document services can be called by either passing the request files by way of streams or

URI (that is, HTTP URL or local file system). For interactive sizing tests, the form design and generated output were passed using HTTP references. The remaining request files used a combination of streams and the local file system.

• It is assumed that Adobe document services are being called in such a way that they can be scaled linearly, horizontally, and vertically.

• It is also assumed that Adobe document services will run proportionally the same speed on various platforms based on the CPU rating of the hardware.

• The ABAP Workbench stack and Adobe document services exist on the same hardware device for optimal configuration.

4.2 Determining SAPS Rating For Each Document Type This section describes how a performance test was constructed to determine the SAPS rating for each Adobe document services interactive document complexity type. These SAPS ratings can then be reused for each customer business case.

As stated above, the criteria for determining complexity of an interactive form will be the number of pages, number of interactive form elements, and the number of static form elements. The sample interactive forms are sized to represent each of four form types: small simple (1-page), small complex (1-page), medium (2-page) and large (4-page). (See Appendix B for a series of form samples.)

Three test sections are defined to represent a typical workflow, form generation, application of security settings, and use of digital signatures. Each interactive sample form includes three populated signature fields:

1. Form Generation

• (A) Adobe document services PDF cache disabled and Reader usage rights applied.

• (B) Adobe document services PDF cache enabled and Reader usage rights applied

2. Application of Security Settings

• (C) Review version of form – no changes or printing permitted

3. Digital Signatures

• (D) Extraction of all signatures

• (E) Extraction of form data when the second signature was applied




Using an optimal number of parallel requests the maximum throughput of the sample forms in pages per hour was determined.


• Let ssph be the number of small simple interactive documents that can be generated per hour.

• Let scph be the number of small complex interactive documents that can be generated per hour.

• Let mph be the number of medium size interactive documents that can be generated per hour.

• Let lph be the number of large size interactive documents that can be generated per hour


cpu_saps = 3000 SAPS (SAPS rating of the computer performing the performance test)

Test SSPH SCPH MPH LPH

A 9360 720 7560 5040

B 36900 30672 36000 31104

C 18720 360 12240 8280

D 5400 360 3600 2520

E 12960 360 8280 6120

Table 3.1 All numbers are in documents per hour

The SAPS rating of each interactive form complexity were determined to be as follows:

• SS_SAPS(small simple) = cpu_saps / ssph

• SC_SAPS(small complex) = cpu_saps / scph

• M_SAPS(medium) = cpu_saps / mph

• L_SAPS(large) = cpu_saps / lph

Test SS_SAPS SC_SAPS M_SAPS L_SAPS

A 0.321 4.167 0.397 0.596

B 0.081 0.098 0.083 0.096

C 0.160 8.333 0.245 0.362

D 0.556 8.333 0.833 1.190

E 0.231 8.333 0.362 0.490

Table 3.2 All numbers are in SAPS per document



4.3 Sizing Guidelines For an interactive form-based application, the SAPS rating is determined based on the number of small simple, small complex, medium, and large documents that the calling application is expected to produce per hour. It also includes the number of each document type that requires security settings and/or digital signature related operations.

The documents that the application produces must be compared with the interactive sample Adobe document services’ documents that have been benchmarked in section 3.2.

With the SAPS ratings for each document and operation type combination (Table 3.2), the total number of SAPS required for an application can be estimated with the following formulas.

For each small simple operation:

SAPS = small simple documents required per hour * SS_SAPS (sum of SAPS for each operation type)

For each small complex operation:

SAPS = small complex documents required per hour * SC_SAPS (sum of SAPS for each operation type)

For each medium operation:

SAPS = medium documents required per hour * M_SAPS (sum of SAPS for each operation type)

For each large operation:

SAPS = large documents required per hour * L_SAPS (sum of SAPS for each operation type)

The Totals SAPS can then be converted to a number of computers by dividing the total SAPS required by the SAPS rating of the computer being considered to run the application. (See www.sap.com/benchmark to determine the SAPS rating of the computer being considered for the application.)

# of computers = Total SAPS / machine_saps




4.4 Interactive Form Sizing Example

Example 6:

This example uses the SAPS ratings calculated in example 5 (see section 4.2).

The customer requires 1500 small, simple documents per hour, 1000 small, complex documents per hour, 1400 medium documents per hour, and 700 large documents per hour. Each of these documents also requires security settings and that the data be extracted from the document after it has been digitally signed. If the forms are both interactive and cacheable, performance gains offered by Adobe document services PDF cache can be realized.


For each document type, the following costs can be combined:

• Generate Form(Test B) + Apply Security Settings(Test C) + Extract Data From Form(Test E)

• SAPS required for small simple documents = 1500 * (0.081 + 0.160 + 0.231) = 708 SAPS

• SAPS required for small complex documents = 1000 * (0.098 + 8.333 + 8.333) = 16764 SAPS

• SAPS required for medium documents = 1400 * (0.083 + 0.245 + 0.362) = 507 SAPS

• SAPS required for large documents = 700 * (0.096 + 0.362 + 0.492) = 665 SAPS


The total number of SAPS required by Adobe document services can be determined by summing the SAPS ADS Server column below.


Small Simple 1500 708

Small Complex 1000 16764

Medium 1400 507

Large 700 665

Total SAPS 18644

The customer would require 18644 / 4700 = CPU power equivalent to approximately four 4-way SMP computers as described above.




5 Appendix A – Print Form Sample

Small Flight Data Print Form



6 Appendix B – Interactive Form Samples

Small Simple Interactive Form

Small Complex Interactive Form



Medium Interactive Form

Large Interactive Form





7 Appendix C –Batch Print Form Samples Small Batch Print Form.

Medium Batch Print Form



Large Batch Print Form



Date post:	07-Nov-2014
Category:	Documents
Upload:	pandian
View:	104 times
Download:	4 times

ADS Sizing Guide

Documents