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 help.sap.com 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).
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.
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.
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).
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.
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).
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: help.sap.com
How do you change the value?
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.
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.
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
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.