Varo (FLM) Sizing Guide for ADS


This document sets out the performance arguments to be used to help size and procure a suitable hardware platform for hosting the Forms Lifecycle Manager (FLM) installation. FLM utilizes Adobe Documents Services (ADS) to render and extract data from PDFs, hence sizing considerations revolve around ADS performance.

Due to the nature of interactive forms it is necessary to make certain assumptions about a specific forms complexity, number of pages of output, parallel requests being processed and the usage profile by the final user community, specifically how uneven the likely usage profile is with respect to time.

This document should be used in conjunction with SAP’s ADS Sizing Guide and ADS Configuration Guide. Specifically Sections 4 of the Sizing Guide which deals with Interact Forms and Section 17 of the Configuration guide which describes how to tune ADS.

This document is provided for information only and Arch takes no responsibility for the suitability of any hardware subsequently chosen.


Limitations of the Standard Sizing Approach

The following is an example of anticipated usage for a set of forms:

Phase 1


1,000 forms per year

3 steps (create plus 2 approve)

Cheque receipt

300 forms per year

3 steps


30,000 forms per year

3 steps

Phase 2


2,000 forms per year

3 steps (create plus 2 approve)


18,000 forms per year

3 steps

Total for phase 1 is therefore 31,300 x 3 = 93,900 form render events per year
Total for phase 2 is therefore 20,000 x 3 = 60,000 form render events per year

Each form render will have an accompanying data extraction step, hence a grand total of 307,800 form processing events per year.

If we space these activities evenly through the working year of 220 days, we arrive at a figure of around 1,400 events per day, or 174 per hour. This corresponds to 87 user sessions per hour.

All of the anticipated forms are 1-page in size.

According to the standard sizing guide, hardware comprising of Dual-CPU Xeon 3.4GHz (a circa 2005 spec machine) with a SAPS rating of 3000 should be able to process around 6000 1-page forms per hour.

However, the resource usage for interactive forms is heavily dependent on the exact timing of when users trigger form processing events and so this figure may not be entirely reliable for genuine interactive scenarios.

User Session Profiling

A typical user session has a profile typically as this:

That is, large parts of the user’s session trigger no ADS activity whatsoever. It is only the initial render and subsequent data extraction that we are concerned with from an ADS sizing perspective.

What we will do is make some assumptions around the user’s behaviour and then examine how that impacts the sizing calculations; we can then vary these as anticipated for the productive scenario.

User session duration 10 minutes

Number of sessions per hour 100 (cf. 87 from anticipated sizing)


User load per hour 100 x 10 = 1000 user minutes
Number of simultaneous users 1000 / 60 = ~17

So given a smooth load on the system we would anticipate an average of around 17 simultaneous users accessing forms at all times, 8 hours a day, 220 days a year.
Now it is theoretically possible that all 100 users would choose to access forms simultaneously, but that is not likely, so we next assume a skewness factor of 3 to our smooth load, to arrive at the:

Expected maximum number of concurrent forms users = 3 x 17 = ~50

Given that the proportion of ADS activity per user session is of the order of 2%, the chances of all 50 users requiring ADS processing simultaneously is vanishingly small, but we now at least have a sensible limit for the typical concurrency likely to occur.

Benchmark Results from the Arch Test Rig

FLM provides profiling tools to simulate the performance of ADS/FLM under different numbers of simultaneous users. The below results illustrate the performance of the system in rendering pdf’s under different configurations of CPU:

































(figures in seconds per form)

Graphically this is shown below.

The machine in question had the following characteristics:

Memory 7.5GB
OS Windows Server 2003 Enterprise Edition
CPU(s) Xeon E5430 @ 2.66GHz (estimate 3000 SAPS per CPU)

The test form is a single page form - a weekly timesheet that Arch always uses for commissioning FLM systems – and it renders out at around 90kb.

The results show that over a small number of users then the response time of ADS is linear with respect to increasing concurrency, which is best case scenario for any machine operating at 100% CPU.

With the machine configured for 4-CPUs (we are referring always to CPU-cores here, not sockets) the response time for up to 5 users was pretty much constant, as up to this level of concurrency the machine was not running at 100% CPU. We estimate each CPU is worth around 3,000 SAPS.

During this test the amount of CPU absorbed purely by the ADS element peaked at 65% whilst the machine overall CPU was running at 100%, which concurs exactly with SAP’s recommendation.

For reference this machine is running an ECC6.0 SP11 SAP system.

Hardware Sizing Recommendations

You must begin with what you consider to be acceptable performance for a certain number of concurrent users; the response curves from ADS are linear, and so it is quite reasonable to extrapolate the concurrency if required.

The analysis in section 3 shows that a figure of 50 maximum concurrent users is not unreasonable.

Note that the figures quoted are for a single page form – for larger forms simply multiply the figures by the number of pages.
Example calculation:

Target – to achieve a response time of 8 seconds for a 2 page form for 40 concurrent users

Based on the above extrapolation it can be seen that the 4-CPU machine should achieve about 8 seconds for a single page form. Therefore doubling the SAPS should provide enough power to process a 2-page form in the same time.

Hardware solution = 2 x 4 x 3,000 = 24,000 SAPS in this case.

In pure hardware terms, on the Arch test Rig, we did not see any appreciable benefit by having extra memory on the server. The key driver is number of CPU cores available, and so the above machine would correspond to an 8-CPU machine, or 4-CPU machine with a higher specification chipset.

Other Considerations

The above testing figures do not include the overhead associated with running on-line scenarios through the FLM Portal, as the tests are pure FLM/ADS rendering times purely on the ABAP stack. Nor do the figures include any network or client machine latency, and so they should be considered best case.

We recommend re-running the above tests after the development server has been commissioned with a more representative form.

We also recommend doing some real stress testing across the network before go-live to ensure the performance is as expected.

Note that each concurrent user requires a dialog work process configuring on the system in the live case. When running the FLM multi-user test program however you must configure a background work process per user (see the FLM IMG documentation for further details).

Configuration of the Java stack for productive use should be carried out in line with SAP’s recommendations.