Adobe Forms Sizing

Sizing Guide

Sizing for Adobe Document Services

Released for SAP Customers and Partners Document, June 2011

Copyright/Trademark

© Copyright 2011 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.

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 expressly

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

Contact

If you have questions or feedback regarding this document

please send an e-mail to [email protected].

__________________________________________________________________________________

1 Sizing Adobe Document Services - SAP Customers and Partners

© 2011 Adobe Systems Incorporated. All rights reserved. Sizing Adobe® Document Services, Release 2.6 February 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.

Sizing Adobe Document Services - SAP Customers and Partners __________________________________________________________________________________

Copyright/Trademark

2 2

TABLE OF CONTENTS 1. Introduction ..............................................................................................................................2 1.1 Functions of SAP Interactive Forms by Adobe .................................................................................2 1.2 Architecture of SAP Interactive Forms by Adobe ..............................................................................2 1.3 Factors that influence the performance ............................................................................................3 1.4 Results of Performance Test ............................................................................................................3 2. Performance Test for Print Form Sizing for Adobe Document Services ...............................4 2.1 Assumptions for Sizing ....................................................................................................................4 2.2 Determining SAPS Rating for Each Document Type ........................................................................4 2.3 Sizing Guideline ..............................................................................................................................5 3. Initial Sizing for Adobe Document Services ...........................................................................6 3.1 Assumptions for Sizing ....................................................................................................................8 3.2 Determining SAPS Rating for Each Document Type ........................................................................8 3.3 Sizing Guidelines .............................................................................................................................9 3.4 Interactive Form Sizing Example .................................................................................................... 10 4. Comments and Feedback ...................................................................................................... 11

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 up to SAP NetWeaver ‘04 SPS16 and higher.

1.1 Functions of SAP Interactive Forms by Adobe 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 SAP Interactive Forms by Adobe 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.


Copyright/Trademark

3 3

Figure 1: Architecture

1.3 Factors that influence the 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 of 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 print form performance test was performed with Adobe document services in SAP Web Application Server 6.40 SPS9 on a single Intel 3.4GHz Xeon-based server with a rating of approximately 1700 SAPS. The interactive performance test was run using the same setup but with a dual Intel 3.4GHz Xeon-based server with a rating of approximately 3000.

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


Copyright/Trademark

4 4

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).


Copyright/Trademark

5 5

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 = 1700 SAPS (SAPS rating of the computer performing the performance test)

sph = 24120 (small documents per hour)

The throughput for the medium, large, and extra-large documents were extrapolated from the small document per-hour result.

mph = 2412.0 (medium documents per hour)

lph = 241.20 (large document per hour)

eph = 24.12 (extra-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 = .0705 SAPS

SAPS(medium per hour) = cpu_saps / mph = .705 SAPS

SAPS(large per hour) = cpu_saps / lph = 7.05 SAPS

SAPS(extra-large per hour) = cpu_saps / lph = 70.50 SAPS

2.3 Sizing Guideline For a printing application, the SAPS rating is determined based on the number of small, medium, large, and extra-large documents 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.0705

Medium

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

= medium documents required per hour * 0.705

Large

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


Copyright/Trademark

6 6

= large documents required per hour * 7.005

Extra large

SAPS = extra-large document required per hour * SAPS (extra-large per hour)

= extra-large document required per hour * 70.5

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, 300 large documents per hour, and 120 extra-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.0705 = 705 SAPS SAPS required for medium documents = 12500 * 0.705 = 8812 SAPS SAPS required for large documents = 300 * 7.05 = 2101 SAPS SAPS required for extra large documents = 120 * 70.5 = 8406 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 705 Medium 12500 8812 Large 300 2101 Extra large 120 8406 Total SAPS 20024 The customer would require 20024 / 4700 = CPU power equivalent to approximately five 4-way SMP computers as described above.

3. INITIAL 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.


Copyright/Trademark

7 7

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.


Copyright/Trademark

8 8

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.

3.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.

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 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


Copyright/Trademark

9 9

The performance test was performed as follows:

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

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

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

Example 3: Performance Test Results

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

SSPH SCPH MPH LPH

A 7200 720 5760 3960

B 16560 12240 17640 10800

C 14400 720 11160 6120

D 4320 360 3240 2160

E 10080 360 7200 3960

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.417 4.167 0.520 0.758

B 0.181 0.245 0.170 0.278

C 0.208 4.167 0.269 0.490

D 0.694 8.333 0.926 1.389

E 0.298 8.333 0.416 0.758 Table 3.2 All numbers are in SAPS per document

3.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.


Copyright/Trademark

10 10

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

3.4 Interactive Form Sizing Example Example 4: This example uses the SAPS ratings calculated in example 3 (see section 3.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. The customer is using a 4-way SMP computer with, according to www.sap.com/benchmark, a SAPS rating of 4700. 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.181 + 0.208 + 0.298) = 1030.5 SAPS SAPS required for small complex documents = 1000 * (0.245 + 4.167 + 8.333) = 12745 SAPS SAPS required for medium documents = 1400 * (0.170 + 0.269 + 0.416) = 1197 SAPS SAPS required for large documents = 700 * (0.278 + 0.490 + 0.758) = 1068.2 SAPS

This application can be represented in a table (shown below). The total number of SAPS required by Adobe document services can be determined by summing the SAPS ADS Server column below. Category Up to #

documents per hour

SAPS ADS server

Small Simple 1500 1030.5 Small Complex 1000 12745 Medium 1400 1197 Large 700 1068.2 Total SAPS 16040.7 The customer would require 16040.7 / 4700 = CPU power equivalent to approximately four 4-way SMP computers as described above.


Copyright/Trademark

11 11

4. COMMENTS AND FEEDBACK Both are very welcome; please send an e-mail to [email protected]

Documents

Adobe Forms Sizing