Skip to Content
Author's profile photo Tom Cenens

Adobe Document Services performance: Multi-processing #sapadmin


Hello SCN Community

Adobe Document Services are widely used but it isn’t really a topic which pop ups much when performance analysis of a Java based SAP system takes place (as far as I have seen that is).

Navigating through I found some interesting information on multi-processing in the configuration documentation of Adobe Document Services.

Checking the performance of Adobe Document Services

You can check the performance of Adobe Document Service in Wily Introscope (part of diagnostics scenario for SAP Solution Manager).

Diagnostics scenario

I like the diagnostics scenario. One of the disadvantages the Java stack has compared to the ABAP stack is still the limited amount of information when problems arise.

The administration tools for ABAP have been around for some time now and are more refined. The administration part for Java is still growing up. I also like Java as a technology so I hope it sticks around. Hopefully SAP refines the administration part so it can have a bright future.

I would recommend implementing diagnostics at least for your productive Java based SAP systems. It can make the difference to finding a root cause by having some information available compared to having very little information. SAPJVM 4.1 will bring some improvements compared to the current platform JDK use for SAP Netweaver 7.0x SAP systems.

Wily Introscope

The best place to look at the performance metrics for Adobe Document Services is the investigator mode in Wily Introscope. You can access the investigator mode in the workstation by accessing it through the main menu bar Workstation –> New Investigator.

The path to the performance data is <hostname> –> SAP Netweaver –> <SID>_<instance>_server<node no> –> WebServices –> Server –> AdobeDocumentServices_Config.


picture 1.1

Wily Introscope has auto tracing on for certain servlets and one of these is the AdobeDocumentServices_Config which will show up in the trace tab (see picture 1.1).


picture 1.2

You can see on picture 1.1 the total response time was around 6 seconds (6007 ms). Below the trace information you can find different views (see picture 1.2) which show you where time was spent.


picture 1.3

Drilling down in the Tree view (also visible in other views) I can see that 38% of the time was spent on renderAllRemote (see picture 1.3).

Multi-processing parameter

The parameter poolmax defines how many parallel processes can be used for Adobe Document Services. You can find the parameter value in the parameter properties of the XML Form Module service in the Visual Administration.

The default value is four, meaning four processes can be used for the XML Form Module service. The recommended value is the number of processors used by your application.

Source of recommendation:

How do you change the value?


picture 1.4

You can change the value in the parameter properties of the XML Form Module in the Visual Administrator. If you want to apply the change to each Java server node you have running (in case you have more than one server node) it is best you use the global configuration tab (see picture 1.4) instead of the cluster tab.


picture 1.5

You can find the XML Form Module service under either Cluster –> Server <node number> –> Services –> XML Form Module or Global Configuration –> Server –> Services –> XML Form Module.


picture 1.6

After clicking the service you will be able to see the parameters on the right pane. After you select the poolmax parameter (see picture 1.5) you will be able to enter a new value in the input field on the bottom of the right pane (see picture 1.6).

After clicking update you still have to hit the save button on top of the right pane to apply the change. In order to use the value of the updated parameter, the visual administrator will request to restart the service (this will make your PDF printing unavailable for 10 seconds give or take). Once the service has been restarted, the service runs with the new parameter value.

Testing the new parameter setting

The best option to test changes in the parameter settings is to have an actual business case where Adobe Document Services is used. That way you can generate load which is as close to the business use as possible.

An alternative if you don’t have a business case or you want to perform some test using simple PDF form printing, you can use ABAP report FP_TEST_00.

First run, don’t panic


picture 1.7

The first use of the service after a restart took place is very slow. This is normal so don’t panic if your response times are very bad when you perform the first test. You can see in picture 1.7 that between 11:43 and 11:44 the first run took place after the service was restarted.

Load influence on performance

The results after changing the parameter poolmax to a higher or even lower value is influenced by the amount of data that needs to be processed. If you have a server with multiple SAP instances and four processors, it might make sense not to set poolmax to a value of four.

If you have multiple SAP systems on that server, those SAP systems will also use resources and utilize processes to do so. You could end up with worse response times for Adobe Document Services as an effect.

If you only use ADS for PDF printing and you don’t really have any heavy use of ADS you will not gain much performance (if you gain performance at all) by increasing the poolmax setting.

The parameter is interesting when the ADS is used a lot and the data to be processed is large enough. Sad enough I don’t have a proper business case with heavy use of ADS to show more data or give proper results. I could only set load on the server using the FP_TEST_00 with multiple pages.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Simon Kemp
      Simon Kemp
      Hi Tom,

      Thanks for this insight into ADS performance. I would just like to add that I think CA Wily gives great insight into exactly what is going on in the JAVA stack which is otherwise a bit of a black box. I have used it successfully many times to diagnose issues and bottlenecks for our customers. I tend to find most customers have it configured but fail to really use it or know what to look for when they use it. It requires a certain knowledge of how Java hangs together and the application being monitored to get the most out of it.


      Author's profile photo Tom Cenens
      Tom Cenens
      Blog Post Author
      Hello Simon

      Thanks for your valuable feedback.

      Out of the diagnostics scenario Wily Introscope bring the most value for me so I can definitely agree with you on that point.

      The way I see it there is a serious lack of Java knowledge and skills necessary to properly support AS Java. It's also one of those things that I get called up for, visit a customer for a day to check their AS Java or give a training on Root Cause Analysis.

      If only there was more information available on the interpretation of the graphics in Wily Introscope. A lot of companies have Wily Introscope but the administrators often don't know how to interpret all those graphs. The help documentation in Wily Introscope is too limited.

      Nothing holding me and other community members back to exchange knowledge on the topic though and help each other learn how to efficiently manage AS Java. I'm always up for information exchange/collaboration.

      Kind regards


      Author's profile photo Tom Cenens
      Tom Cenens
      Blog Post Author
      Hello Simon

      Thanks for your valuable feedback.

      I can only say I totally agree with your comment.

      It's highly recommended to install CA Wily to monitor/interpret what goes on with AS Java based SAP systems.

      Understanding how Java technology works (garbage collection etc) is important to provide proper support for AS Java based SAP systems.

      I hope in the future we will see more knowledge sharing around Wily Introscope so we can all learn from it.

      Kind regards


      Author's profile photo Former Member
      Former Member
      Hi Tom,

      You highlight a very important point related to the use of Java applications such as Adobe Document Services.  Parameters that determine the number of available threads can easily restrict a Java application from using all the available hardware resources and performing to its full potential.

      I have used Wily Introscope for similar investigations for Process Integration and Portal, where the default parameters caused significant bottlenecks as the load was increased.  It's a great tool not only for online monitoring, but also for investigating the cause of issues that once they have occurred.

      Thanks for sharing this.


      Author's profile photo Tom Cenens
      Tom Cenens
      Blog Post Author
      Hello Jon

      Thanks for your valuable feedback.

      Things like ADS performance and parameter settings are often overlooked when a SAP system is being reviewed or a service is performed on it.

      It is indeed important to challenge what is supposed to be default. After all, who sais there is no better value that suits the specific use case.

      The amount of application threads is a nice metric to test performance on through Wily Introscope. I have seen it scale with reponse times so it is definitely worth doing some tests on.

      Kind regards